当前位置：首页 > news >正文

【Android 项目实战 01】从乘客下单到司机抢单：网约车平台 App 的设计与实现（Spring Boot + MySQL）

news 2026/6/23 19:41:54

先说结论

• 这是一个课程设计 / 毕业设计型网约车平台：Android 端承担用户操作，Java + Spring Boot 提供后台接口，MySQL 负责业务数据持久化。

• 项目已覆盖乘客、司机、管理员三类角色的基础业务闭环；本文重点讲架构、订单流转、数据表与后端关键实现，不把它包装成生产级商业平台。

1. 项目要解决什么问题？

传统电话约车往往依赖人工描述上车点、目的地与乘车需求，信息传递成本高，也不利于订单记录、司机接单和平台审核。本项目将这些操作拆分为可追踪的数据流程：乘客提交订单或约车信息，司机查看并处理抢单信息，管理员在后台统一管理用户、站点内容与订单数据。

从项目定位看，它不是简单的“信息展示 App”，而是一个围绕账号、订单、审核与内容管理展开的轻量级业务系统。文章中出现的功能和字段均来自项目论文与项目截图；为便于阅读，部分原始代码已压缩为结构化示例。

2. 三类角色如何形成业务闭环？

角色	核心操作	系统侧对应模块
乘客	注册登录、浏览首页和资讯、维护个人信息、提交乘客订单与约车信息	用户注册、用户信息、前台首页、资讯列表、乘客订单
司机	维护司机与车辆相关信息、查看并处理抢单相关信息	司机管理、抢单信息、约车信息
管理员	审核和管理平台内容、用户与订单数据	轮播图、公告栏、管理员/乘客/司机、新闻、顺风车、约车信息、制单信息、乘客订单、抢单信息

2.1 一条订单从提交到处理的路径

乘客在 Android 端完成账号注册和登录，并在订单页面录入起点、终点、联系方式、下单时间与乘车人数等信息。
后端接收请求后，将订单写入 passenger_order（乘客订单）等业务表；创建逻辑通过事务控制，避免出现半写入状态。
司机侧围绕 order_grabbing_information（抢单信息）处理抢单相关数据，订单中保留车牌、司机、金额、状态等字段，为后续追踪留出空间。
管理员在后台统一查看与维护约车、订单、抢单和用户信息，并可处理审核相关字段。

3. 技术栈与架构设计

层级	选型	在项目中的职责
移动端	Android	承载注册、登录、首页浏览、用户信息和乘客订单等操作入口。
后端	Java + Spring Boot	通过 Controller 接收接口请求，完成登录、注册、上传、订单新增等业务处理。
数据层	MySQL	保存用户、乘客、司机、约车、顺风车、乘客订单、抢单等业务数据。
会话控制	Token	登录校验通过后生成并保存访问令牌，返回用户信息与登录状态。

3.1 结构不复杂，但分层要清楚

Android 客户端

→

Controller / REST 接口

→

Spring Boot 业务层

→

MySQL 数据库

图 1 文章化后的系统链路：用户操作进入接口层，业务逻辑统一处理后写入数据库

论文中将后台与客户端分开描述。改成技术文章后，更值得强调的是：Android 端只负责交互和请求发起；登录校验、订单写入、文件上传等能力集中在后端。这种拆分能让后续维护、测试和功能扩展更直观。

4. 数据库：围绕“人、车、单、状态”建模

原论文给出了较完整的数据表清单。CSDN 正文没有必要把所有字段逐行罗列，更适合展示真正支撑业务闭环的实体关系。下面是从原表结构中提炼出的核心模型。

实体 / 表	关键字段举例	业务作用
passenger（乘客）	passenger_number、passengers_name、region、examine_state、user_id	关联平台用户，保存乘客基本信息与审核状态。
driver（司机）	driver_no、vehicle_name、license_plate_number、name_of_driver、user_id	维护司机、车辆与用户账号的关联。
passenger_order（乘客订单）	starting_point、end、order_time、number_of_passengers、unit_price、ride_amount	记录乘客下单的基本信息和订单金额相关字段。
order_grabbing_information（抢单信息）	odd_numbers、driver_no、vehicle_name、quantity_of_order_grabbing、pay_state	承接司机抢单与订单处理后的扩展信息。
car_hailing_information（约车信息）	appointment_no、place_of_origin、destination、driver_no、pay_type、examine_state	保存预约与约车信息，以及支付、审核等状态字段。
free_ride（顺风车）	place_of_origin、destination、seats、release_date、ticket_unit_price	存储顺风车发布信息与座位、票价等字段。
字段设计中值得保留的思路 • 把审核状态、支付状态、推荐标记、创建时间和更新时间保留在业务表中，后台审核和运营统计才有落点。 • 订单信息里同时存储联系人、路线和人数等快照字段，有助于在订单记录里保留当时提交的关键信息。 • 后续迭代时，可以把订单状态设计为统一状态机，避免“审核状态、支付状态、抢单状态”分散更新。

5. 后端关键实现：只讲读者最关心的 3 个点

原论文中有较长的代码片段。为了让文章更易读，这里不重复堆砌 Controller 全量代码，而是保留登录、订单写入和文件上传三个最能说明系统实现的部分。以下均为根据论文代码整理后的简化示例，字段和 Service 名称应以实际项目为准。

5.1 登录：支持多种账号标识，并校验用户状态

登录逻辑会根据用户名、邮箱或手机号构建查询条件，随后校验用户是否存在、密码是否匹配、用户组是否存在、审核状态是否通过以及账号是否可用；通过后保存 Token，并将用户信息返回给客户端。

示例 1 登录接口的核心校验顺序

// 根据论文登录接口整理的伪代码
@PostMapping("/login")
public Result login(LoginRequest req) {
User user = userService.findByUsernameOrEmailOrPhone(req);
if (user == null || !passwordMatches(req.getPassword(), user.getPassword()))
return error(30000, "账号或密码不正确");
if (!groupService.exists(user.getUserGroup())
|| !user.isApproved() || user.getState() != 1)
return error(30000, "当前账号不可登录");
String token = tokenService.createAndSave(user);
return success(Map.of("token", token, "user", user));
}

5.2 创建订单：写库动作要放进事务边界

乘客订单新增接口在论文代码中使用了 @Transactional。虽然当前示例只有一条插入动作，但这为后续“写订单 + 写抢单记录 + 更新状态”等多表操作预留了可靠边界。

示例 2 乘客订单新增接口

@PostMapping("/passenger-order/add")
@Transactional
public Result createPassengerOrder(@RequestBody Map<String, Object> payload) {
// 实际项目中应补齐：字段校验、用户身份校验、订单号生成等
passengerOrderService.insert(payload);
return success(1);
}

5.3 上传：先保证目录存在，再落盘保存

约车信息相关页面需要上传文件或封面时，后端会先检查文件是否为空，再检查目标目录是否存在；目录创建成功后，将文件保存到目标位置并返回路径信息。

示例 3 文件上传的基础处理

@PostMapping("/upload")
public Result upload(MultipartFile file) throws IOException {
if (file.isEmpty()) return error(30000, "没有选择文件");

File targetDir = new File(uploadDir);
if (!targetDir.exists() && !targetDir.mkdirs()) {
return error(30000, "创建目录失败");
}

File dest = new File(targetDir, buildSafeFileName(file));
file.transferTo(dest);
return success(Map.of("path", dest.getPath()));
}

继续迭代时，建议优先补这 3 件事

• 密码不应以可逆形式直接存储；应采用安全哈希方案，并在登录时做比对。

• 上传文件要限制类型、大小与文件名，避免把非业务文件直接暴露在可访问目录。

• 订单接口补齐参数校验、幂等控制、订单号生成和角色权限校验，再考虑抢单并发控制。

6. 项目界面：用真实截图证明功能已经落地

技术文章里截图不是越多越好。保留能说明核心模块的界面即可：一张后台管理截图用于证明管理端能力，一到两张移动端截图用于展示用户端入口和订单填写页面。以下为论文中已有的项目截图。

图 2 后台信息管理页面：以列表方式处理约车 / 用户 / 订单等数据

移动端首页：展示约车相关内容入口

乘客订单：填写路线、联系人等信息

图 3 Android 端界面示例：前台入口与乘客订单表单

7. 测试范围、项目边界与复盘

论文中将系统测试分为黑盒测试和白盒测试，并对注册登录、信息管理、订单相关页面等基础功能进行了验证。将这部分改成 CSDN 文章时，不建议写成“系统完美、商业可用”一类结论；更可信的表达是：课程项目已完成基础业务功能验证，仍有面向真实出行场景的工程化改进空间。

已覆盖 / 已展示	尚未作为本项目重点呈现的能力
注册、登录、用户状态校验、Token 登录态、后台信息管理、订单新增、抢单信息、文件上传、Android 页面展示	实时定位与地图导航、订单并发抢占策略、真实支付接入、消息推送、风控审核、分布式部署与高可用