先说结论• 这是一个课程设计 / 毕业设计型网约车平台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)Transactionalpublic Result createPassengerOrder(RequestBody MapString, 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 页面展示实时定位与地图导航、订单并发抢占策略、真实支付接入、消息推送、风控审核、分布式部署与高可用8. 写在最后从“能跑”到“更像产品”这次实现的最大收获不是做出多少页面而是把一个看似分散的网约车业务拆成了账号、角色、订单、审核和内容管理等可落库、可操作的模块。Android 端让用户完成输入Spring Boot 端承接校验和业务处理MySQL 端保留过程数据三者共同形成了一个最小可用的业务闭环。后续若继续完善我会优先补齐订单状态机、权限控制、密码与文件安全、异常处理和并发抢单策略再向实时地图、支付和通知能力扩展。对于学习型项目而言先把主业务链路讲清楚比堆砌“全功能大而全”更有价值。— 完 —本文为项目实践记录截图与代码请以实际可公开、可授权的版本发布。
【Android 项目实战 01】从乘客下单到司机抢单：网约车平台 App 的设计与实现（Spring Boot + MySQL）
先说结论• 这是一个课程设计 / 毕业设计型网约车平台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)Transactionalpublic Result createPassengerOrder(RequestBody MapString, 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 页面展示实时定位与地图导航、订单并发抢占策略、真实支付接入、消息推送、风控审核、分布式部署与高可用8. 写在最后从“能跑”到“更像产品”这次实现的最大收获不是做出多少页面而是把一个看似分散的网约车业务拆成了账号、角色、订单、审核和内容管理等可落库、可操作的模块。Android 端让用户完成输入Spring Boot 端承接校验和业务处理MySQL 端保留过程数据三者共同形成了一个最小可用的业务闭环。后续若继续完善我会优先补齐订单状态机、权限控制、密码与文件安全、异常处理和并发抢单策略再向实时地图、支付和通知能力扩展。对于学习型项目而言先把主业务链路讲清楚比堆砌“全功能大而全”更有价值。— 完 —本文为项目实践记录截图与代码请以实际可公开、可授权的版本发布。
