一到毕业设计季，我身边就有不少同学来问选题。说句实话，管理系统类项目做得好的不多，大部分最后都变成了“登录+增删改查”四件套，答辩时被问一句“你的难点在哪”就卡住了。不过基于SpringBoot的代驾管理系统是个例外，它表面上是管理系统，内核却是一个实时业务闭环：订单状态流转、司机并发抢单、动态计费、第三方地图集成，每一个环节都有真东西可以展开讲。
这篇内容比较长，我会把这个项目从需求拆解、技术选型、数据库设计，到下单、抢单、结算的完整代码逻辑，再到地图和计费里最容易踩的坑，最后连答辩演示和追问应对都一起讲清楚。如果你正在准备这个选题，或者想让自己的管理系统类毕设摆脱“纯CRUD”的印象，这篇文章可以当成一份完整落地参考。
1. 先从需求下手：一个代驾系统背后到底有几类人在用
很多毕设项目做得不像真实系统，根子不在代码，在于需求没拆明白。代驾业务坐在用户角度想很简单——叫个司机来帮我开车。但一旦把系统拆开，你会发现至少有三类角色、三个完全不同的使用场景，背后的数据结构和功能模块完全不同。
1.1 三类角色的核心诉求
用户要的是“快”和“心里有数”：打开小程序或App，填上起点，能看见大概要花多少钱，下车后能支付、能评价。司机要的是“单子”和“收入”：打开司机端能看到附近可抢的订单，抢单后去接人，开始服务、结束服务，最后能看见这一单挣了多少。管理员要的是“可控”：司机注册上来得审核资质和驾照，订单出问题能查到原始记录，还要能设置起步价、夜间加价这些计价规则。
如果你在写代码之前，先把这三类角色的操作界面和流程画出来，后面的表结构会非常清晰。我当时是先画了三张草稿纸的角色流程图才开始建表，过程里几乎没怎么返工，这个习惯值得复制。
1.2 核心业务闭环：从叫单到结算的完整故事
把三类角色串起来，整个系统的主干是一条业务链：用户下单，系统根据起点计算预估费用，生成待接单订单；司机在司机端看到订单并抢单；司机到达起点，用户确认上车；行程结束，按实际里程和时长结算费用；用户支付并评价。
这条链完整跑通，项目就算立住了。我见过太多失败的案例：用户下单了，司机端看不到；司机点“开始服务”，订单状态没变；到了结算环节，金额算出来对不上。这些问题基本都是需求阶段没把状态流转画清楚造成的，提前画一张“订单状态流转图”就能规避掉一大半。
1.3 边界收缩：毕设版本里可以砍掉哪些功能
代驾业务本身能做的东西非常多，但毕设时间有限，得有取舍。我建议弱化或砍掉的东西包括：实时轨迹跟踪（没有富余时间就别碰WebSocket，用“到达/开始服务/结束服务”三个状态节点足够）、真实支付对接（做一个模拟支付页）、复杂的优惠券和拼车体系（留一张简单的券规则表演示即可）。
砍完之后，核心依然是完整的：下单、抢单、服务、结算、评价。别小看这个闭环，很多做CRM、做进销存的毕设，业务链完整度还不如这个。
2. 技术选型复盘：这套组合也许不够炫，但足够稳
毕设技术选型有一个隐藏雷区：跟着教程走没问题，但教程版本新、本地环境旧，一运行全是环境报错。我经过几轮折腾，确定了一套真正稳妥的组合：SpringBoot 2.7.x + MyBatis Plus + MySQL 8 + Redis + JWT。前端用Vue做管理后台，用户端和司机端做成H5页面就够了。
2.1 SpringBoot版本选择：别一上来就用3.x
SpringBoot现在都出到3.x了，但如果你不是特别清楚javax到jakarta这个包名迁移的细节，我建议踏踏实实用2.7.x。原因很简单：网上大部分教程、同类毕设参考代码、视频课程全部基于2.x。用3.x当然不是不行，只是当你遇到“Spring Security配置怎么全变了”“这个依赖怎么不见了”这类问题时，排查成本会直线上升。毕设时间宝贵，稳定压倒一切。
版本这一块还有个小建议：JDK用8或11。不是17不好，而是很多同学电脑上的旧项目、旧依赖会跟新JDK打架，一个“Unsupported class file major version”报错就能折腾一下午。选一套自己用得最顺手的版本组合，比追求最新版本重要得多。
2.2 持久层与缓存：MyBatis Plus + Redis的分工
MyBatis Plus在这个项目里的地位很关键。代驾系统的订单表字段多、查询条件多，按状态查、按司机查、按时间查，用条件构造器写起来比手写SQL快，而且代码量少，答辩讲起来也轻松。特殊查询，比如管理后台的对账统计，用@Select注解直接写原生SQL也不麻烦。
Redis在系统里有两个关键用处。第一是订单缓存：待接单订单的起点经纬度和预估价格写进Redis一份，司机端拉取可抢订单列表时直接读缓存，速度比查库快很多。第二是抢单时的并发控制，这个在后面的抢单环节细讲。
至于要不要上微服务、加RabbitMQ、Kafka之类的消息队列——说实话，对于毕设完全没必要。单机SpringBoot处理这个量级的业务绰绰有余，硬上微服务只会给自己挖坑。技术选型的核心逻辑是“技术服务于业务闭环”，不是“用得多就加分”。
2.3 认证与地图：两个务实的选择
登录认证我用的JWT。毕设场景下，JWT能把用户、司机、管理员三种角色统一用token识别，前端把token存起来每次请求带上就行，省去了Session存储和共享的麻烦。
这里有个必须处理的细节：不同角色的接口权限一定要分开校验。我是在拦截器里根据注解判断角色，比如@RequireRole("driver")只允许司机身份的token访问，否则直接返回403。没有这层控制，系统会出现“用户能访问司机接口”这种低级问题，答辩时很减分。
地图部分，毕设要选“能免费调用、文档清晰、返回数据简单”的方案。我当时选用的是某主流地图开放平台的Web服务API，用到了两个能力：逆地理编码，把经纬度转成中文地址展示；路径规划，计算两点间的驾车距离和预计时间。这里先敲个黑板：千万不要用两点间的直线距离算预估价，代驾走的是道路，直线距离和真实路径偏差非常大，后面我会专门讲怎么处理。
3. 数据库设计：我踩过的坑和最终沉淀下来的表结构
数据库设计是整个项目的基石，也是我帮别人审代码时发现问题最多的地方。很多人一上来就建一张巨大的订单表，把所有字段塞进去，项目越做越别扭。按照前面的需求拆解，这套系统六张核心表就够了。
3.1 六张核心表的定位
用户表（sys_user）存所有角色的公共账号信息，通过role字段区分是普通用户、司机还是管理员。司机有额外的资质信息，单独拆一张司机信息表（driver_info），存真实姓名、身份证号、驾驶证号、驾龄、审核状态等。这样用户表保持干净，司机特有字段不会污染整个账号体系。
订单表（order_info）是整个系统最重要的表，围绕订单状态展开。字段包括订单号、下单用户、接单司机、起点终点的经纬度和地址、订单类型、各状态节点的时间戳、预估金额、实际金额、支付状态。这里要特别注意：订单号不要用数据库自增id，建议用“日期+随机数”的方式生成。用自增id的话，订单号会直接暴露一天的订单量，而且后期做日志查询也不方便。
费用明细表（order_cost）记录一单的最终费用拆解——基础价、里程费、时长费、夜间费，合计金额。把费用单独拆一张表的理由很实在：以后计价规则改了，历史订单的费用明细仍然有据可查。评价表、司机审核记录表、管理员操作日志表这三张表，是把系统的业务完整性撑起来：评价表让用户端闭环有结尾，审核记录表能体现“司机提交资质、管理员审核”的流程，操作日志给管理后台留痕。
3.2 订单状态字段：用数字和常量，别用中文字符串
订单状态是整个项目里最容易写乱的地方。我见过有人用varchar存“已接单”“已完成”这种中文，代码里到处比较字符串，加一个状态就要改一堆地方。正确做法是统一用tinyint存状态码，后端定义一个常量类或者枚举，比如：
0待接单，1已接单，2司机已到达，3服务中，4已完成，5已取消，6异常关闭。
每次状态变更时，同时更新对应的时间戳字段，比如接单时间、到达时间、开始服务时间、完成时间。这样后面算等候费、算服务时长都有数据支撑，不用再到处猜“这单到底几点开始服务的”。
3.3 金额字段用decimal，费用明细必须落库
订单表里的预估金额、实际金额属于冗余字段，存上去是为了列表展示方便，不用每次去关联计算。真正的费用账本放在order_cost表。预估金额在下单时就算好写进订单表，实际金额在行程结束时算好更新订单表，同时往order_cost表插一条明细。这样既支持快速列表展示，也支持支付页展示明细。
我早期踩过一个典型的坑：金额字段一开始用的double，后来发现金额运算出现0.1+0.2不等于0.3这类问题，结算金额偶尔多几分钱。全部改成decimal(10,2)，金额运算用BigDecimal，问题彻底消失。这个细节值得在答辩时主动提出来——属于实战中总结出的规范，比背教材例子有说服力。
4. 核心链路逐段拆解：从用户下单到司机完单
选型定了、表建好了，接下来是最核心的部分——把业务链路用代码串起来。我按“下单、抢单、服务、结算”四个阶段来讲，每个阶段的坑都是实际走了一遍才发现的。
4.1 下单与费用预估：先把预估金额算明白
用户下单时只做两件事：填起点、选服务类型，比如舒适型、商务型。如果填写了目的地，可以同步展示预估费用；如果没填目的地——代驾最常见的场景是用户喝完酒直接说“送我回家”——就先按起步价和基础信息生成订单，等行程结束统一结算。
下单接口的核心逻辑是：接收起点的经纬度与地址描述，生成订单号，插入订单表且状态为待接单，把订单ID写进Redis待接订单缓存，返回订单号和预估金额给前端。这里有一个容易被忽略的点：订单落库和写Redis不是强一致关系。正确做法是订单先落库，Redis写入失败不阻塞主流程，司机端取不到缓存时兜底查数据库，两边数据不会冲突。
预估距离这个动作，不要塞进下单主流程里，否则用户点“立即叫代驾”会明显卡顿。更好的是做一个独立的“费用预估接口”，前端拿到预估公里数之后，按规算出“8.8元起步、预计总费用35-50元”这种区间价格展示给用户。
4.2 抢单环节：一条SQL解决并发冲突
司机端抢单是整个项目最有技术含量、也最容易被答辩老师追问的地方。它的本质问题是：同一个订单被多个司机同时看到，大家都点了抢单，怎么保证只有一个人成功？
很多人第一反应是加锁，synchronized或者Redis分布式锁。但说实话，对这个量级，一条带条件的Update语句就足够了：
UPDATE order_info SET driver_id = #{driverId}, status = 1, accept_time = NOW() WHERE id = #{orderId} AND status = 0 AND driver_id IS NULL这条SQL的精髓在于用条件保证幂等：只有订单还是待接单状态、且没有司机时，这个Update才会更新成功。返回影响行数是1，说明抢到了；返回0，说明被别人抢先了。整个过程是数据库层面的原子操作，不需要额外锁，代码只有几行。
Redis在这儿的角色是给“可抢订单列表”做热数据缓存，但抢单动作一定要打到底层MySQL执行上面的SQL。我当时写完之后专门写了个脚本模拟30个司机同时抢一单，结果只有1个人成功，其余影响行数全是0。这个测试过程可以在答辩现场演示，视觉冲击力很强。
4.3 行程结束与最终结算：把账算明白并写进一个事务
司机到达起点后点“我已到达”，订单状态从1切到2，记录到达时间。用户上车，司机点“开始服务”，状态切到3，记录服务开始时间。到达目的地后点“结束服务”，这一下要做的事情最多：调用地图API算真实行驶距离，按计费规则算实际费用，更新订单表金额，写费用明细表，把状态置为待支付。
这三件事必须放在同一个事务里，否则会出现“订单已完成但费用明细缺失”或者“费用算好了但金额没更新”的脏数据。我最初是分步写、没加事务，测试时偶尔复现“已结算但看不到明细”，后来统一加上@Transactional注解才解决干净。
理论上，状态从待接单到已接单再到完成，每一次变更都应该做合法性校验，不允许从“待接单”直接跳到“已完成”这种不合理的流转。实现方式很简单：在状态变更的地方检查当前状态是否是目标状态的前置状态，不满足就直接报错。把状态机校验写严谨了，不光数据干净，答辩时也是一个可以主动讲的工程细节。
4.4 异常兜底：订单长时间没人接怎么办
真实系统里最怕用户下了一单，司机一直不接，用户干等着。我加了一个定时任务，每30秒扫描一次超过3分钟还没司机接的订单，自动把状态改成“已取消”，同时把Redis里对应的缓存数据清掉。这个功能用Spring自带的@Scheduled注解就能实现，不需要引入其他框架。
另外我建议在司机点“到达”之后，加一个用户确认环节再开始服务。虽然真实平台的司机可能到了就直接点开始，但毕设里加一个确认步骤，订单状态流转的逻辑更完整，答辩演示也更有说服力，不会被问“这不就是司机自己说了算吗”。
5. 地图接口与计费细节：这里最容易“看似做完实则翻车”
我帮别人看代驾系统毕设时，十个有八个栽在地图和计费这一块。不是功能没做，而是细节没到位。这一节把最容易出问题的三个点单独拿出来讲。
5.1 用路径规划距离，绝不能用直线距离
这是第一个大坑。地图开放平台通常提供两种距离计算方式：一种是按道路网络计算的驾车路径规划距离，一种是两点间的直线距离。很多人图省事，直接用坐标算直线距离，结果用户从A点到B点实际开了9公里，界面预估显示5.5公里，结算时用户肯定不认。
正确做法是调用路径规划接口，取返回的distance字段作为实际里程。这个接口不仅有距离，还返回预计行驶时间，对计费非常有用。调用时有个性能问题容易踩：不要在用户高频操作里反复调地图接口。比如用户在地图上移来移去改起点，要做防抖，或者把“选择地点”和“预估费用”分成两步，只在确认下单时才发起路径规划请求。
坐标还有个细节——国内主流地图平台拿到的基本是GCJ-02坐标系，和GPS原始坐标存在几百米的偏移。我的建议是全程使用地图平台返回的坐标，不要做任何自行转换，更不要拿另一套来源的坐标直接丢到地图上画点。
5.2 计费规则怎么设计才像真实业务
真实的代驾计费大概是“起步价加超里程费加时长费加夜间附加费”，我在系统里拆成几个参数：起步价对应起步里程，超出后按每公里单价计费；司机到达后等待超过免费时长，按分钟收等候费；夜间时段，比如23点到次日5点，在基础价格上浮一定比例。
这些参数在管理后台做成可配置项，数据库存一张计费配置表。实际结算逻辑是：
总费用 = 起步价 + max(0, 实际里程 - 起步里程) × 里程单价 + max(0, 等候分钟 - 免费等候分钟) × 时长单价，若是夜间单，总费用再乘以（1 + 夜间加价比例）。
这里要提醒的是：实际里程必须以地图路径规划返回的距离为准，不能拿起点终点坐标自己算。地图返回的距离单位是米，计算时转成公里并保留一位小数。预估金额可以是一个区间，但最终结算金额必须精确到分。
5.3 缓存数据要及时清，不然列表永远有个抢不到的订单
这个坑很隐蔽，但几乎每个人都会踩一次：Redis里存了待接单订单列表，结果订单被抢走、被取消了，Redis里那条数据没删，司机端的列表里就会一直躺着一个点进去提示“订单已被抢走”的脏数据。
我的方案是给订单状态变更统一加一个钩子：只要订单状态从待接单变成其他任意状态，立即删除Redis里对应的缓存key。测试下来，列表数据始终干净。这个问题的本质是“缓存与数据库的一致性问题”，能在答辩时主动讲出来，比单纯说自己用了Redis高级很多。
6. 答辩演示与亮点提炼：让评委觉得你不只是在堆CRUD
最后这部分，补一下很多人会忽略但实际很重要的内容——你的项目怎么讲。代码写完了，功能跑通了，但答辩时前30秒没让评委抓住重点，后面的功夫就容易打折扣。
6.1 演示脚本这样编排
我建议准备一段两分钟左右的主链路演示：先注册两个角色账号，一个用户一个司机，管理员提前在后台建好；管理员审核司机资质；用户下单；司机端看到订单并抢单；司机到达、开始服务、结束服务；用户查看费用明细并模拟支付；双方评价；最后切到管理后台，能看到这一条订单的完整流程和时间戳。
这套链路有七八步，每步都有页面变化和数据更新，比先花十分钟介绍技术架构再开始演示要有效得多。技术架构一页PPT带过就行，剩下的时间全留给业务链路。
6.2 容易被追问的问题清单
我整理了评委大概率会问的几个问题，每个都给出简短应答思路：
“多个司机同时抢一单怎么保证不冲突？”——答：订单表状态字段加条件更新，数据库层保证原子性，然后贴出那条Update语句。
“预估金额和实际结算不一致怎么办？”——答：预估金额仅供用户参考，最终费用以行程结束时按实际里程计算为准，支付页展示完整费用明细。
“如果地图接口免费调用次数用完了怎么办？”——答：调用失败时做有限次重试，仍失败则提示用户稍后查询，或者降级为直线距离估算并在页面上明确标注是估算值。
“突然断网断电，订单一直卡在服务中怎么办？”——答：后端加一个补偿任务，把超过服务时长上限仍处于服务中的订单标记为异常待人工处理，体现你对异常流程有考虑。
“为什么不用WebSocket做实时推送？”——答：毕设场景下司机端用定时轮询或SSE轻量推送即可满足需求，引入WebSocket会增加复杂度但对核心业务价值有限，如果你的演示需要实时性更强，可以简单用SSE实现单向前端推送，代码量不大。
6.3 一个真实的加分项：主动讲你的踩坑过程
不要只讲“我做了什么”，适当讲“我一开始做错了什么、后来怎么排查解决的”，在评委那里的可信度会高很多。比如金额用double导致的精度问题、Redis缓存脏数据问题、直线距离和路径距离的偏差问题，每一条都是真实工程教训。简短讲30秒，比你背诵十个技术名词更有说服力。
最后说几句
整个项目从头到尾做下来，我最大的感受是：毕设想要出彩，靠的不是炫技，而是把一个业务闭环做完整、做扎实。代驾管理系统最吸引人的地方就在于它天然包含了状态流转、并发抢单、动态计费、第三方地图集成这些“活”的东西，任何一个单点都能在答辩时展开成有价值的技术故事。
如果你也准备做这个选题，建议先按文中的节奏把需求、表结构、主链路走通，再去补管理后台和统计报表。剩下的时间宁可多打磨演示脚本和追问回答，也比无限加功能更有价值。在地图API的选择上，直接用你用得最顺手的主流平台就行，不同平台返回的数据结构略有差异，但只要抓住“路径规划算距离、逆地理编码转地址、坐标系统一”这几个关键点，换平台也只是改改返回字段的解析而已。
