做这类“基于SSM+JSP的代驾应用系统”毕设项目，我接触过不少同学的版本。说句实在话，题目看起来不难，但要把代驾业务从下单、派单、司机接单，再到计价、支付、评价，这一整条链路做成一个能演示、能答辩、能交付源码的系统，里面值得琢磨的细节并不少。Spring+SpringMVC+MyBatis这个“老牌组合”之所以到现在还是高校毕业设计的常客，是因为它能把三层架构讲得很直观，JSP又能让评审老师一眼看到页面渲染逻辑，整套源码的可读性远比Spring Boot自动封装出来的项目强。
我写这篇文章，不是给你贴一份现成的代码就完事，而是站在“我要自己把它做出来并顺利通过答辩”的角度，把技术选型、数据库设计、核心功能实现、部署调试、答辩准备这几块完整拆开讲。无论你是打算直接用这套题目，还是想换成顺风车、租车、跑腿系统，只要把业务对象换一换，底层的设计思路是通用的。
1. 项目拆解：为什么选 SSM + JSP，代驾系统要做什么
1.1 技术选型的现实考量
很多同学选这个题目时第一反应是：为什么不直接用Spring Boot？答案其实很现实。大部分高校的《Java Web开发》课程还停留在一手JSP一手Servlet的阶段，到了毕业设计阶段，用SSM正好能把“Spring管对象、SpringMVC管请求、MyBatis管数据库”这条主线完整呈现出来。
Spring Boot天然做了大量自动化配置，依赖少了，页面也通常用模板引擎或前后端分离，虽然开发快，但你在答辩时能讲的内容反而变少。老师问“请求是怎么从页面走到数据库的”，你如果只答“加个注解就行”，场面会很尴尬。SSM这套则不同，从web.xml到spring-mvc.xml，再到applicationContext.xml，每个配置都在明明白白告诉你请求、对象、事务是如何串联的。
代驾系统的业务场景也很适合做毕设。它既有C端用户的叫车流程，又有B端司机的工作台，还有管理后台的数据管理，角色多、状态多，天然能撑起一篇论文的章节结构。而且代驾不涉及物流库存这类复杂概念，核心集中在订单流转上，学生完全有能力在三个月内独立完成。
1.2 代驾场景的核心业务闭环
设计系统之前，一定要先把业务闭环画出来。我通常建议同学们在白纸上把这条链路写一遍：乘客注册登录，填上下车地点，系统预估价格，提交代驾订单；司机端看到待接单列表，抢单成功，到达起点后点击开始服务；司机驾驶车辆到达目的地，点击结束行程，系统根据实际里程计算出最终费用；乘客确认支付，订单完成后可以互评。
这个闭环看起来简单，但它决定了数据库表和订单状态的设计方向。你的页面可以做得朴素一点，但业务状态必须完整。很多毕设系统死在“看起来功能很多，实际只能增删改查”这个评价上。代驾的核心不是页面展示，而是订单在状态机里的流转是否严谨，司机抢单时并发处理是否合理。
1.3 角色与功能清单
系统按角色拆成三端，功能清单如下表所示。先定功能再做页面，能避免后期返工：
| 角色 | 核心模块 | 主要功能 |
|---|---|---|
| 乘客端 | 用户注册登录、代驾下单、订单查询、在线支付、评价 | 填写起终点、预估价格、等待司机接单、查看行程状态、完成支付 |
| 司机端 | 司机工作台、接单大厅、订单详情、个人中心、行程记录 | 切换接单状态、抢单、开始服务、结束行程、查看收入记录 |
| 管理后台 | 用户管理、司机管理、订单管理、数据统计、系统公告 | 审核司机资质、查看实时订单、统计交易金额、处理投诉建议 |
功能清单确定以后，再对照“用户故事”去细化接口。比如乘客下单需要传什么参数，司机端刷新订单列表调哪个接口，管理员统计营业额是查哪张表，这些细节在写代码前就要想清楚。我不太建议直接在IDE里边想边写，因为业务一旦复杂，后面改表结构会非常痛苦。
2. 数据库设计与订单状态机
2.1 表结构设计与关系
代驾系统的核心表只有四张：用户表、司机表、订单表，再加一张司机认证信息表就够用。过多拆分表会增加联查复杂度，过少合并又会让字段冗余，下面这套是我觉得比较平衡的方案。
用户表保存登录账号和乘客信息，司机表单独建一是因为司机有审证状态、服务状态等额外字段，二是后续要扩展司机考核评分时不用动用户表。
CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(30) UNIQUE NOT NULL, password VARCHAR(64) NOT NULL, real_name VARCHAR(30), phone VARCHAR(20), type TINYINT COMMENT '0-乘客 1-司机', create_time DATETIME ); CREATE TABLE t_driver ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, name VARCHAR(30), phone VARCHAR(20), license_no VARCHAR(30), car_no VARCHAR(20), status TINYINT DEFAULT 0 COMMENT '0-休息 1-接单中', total_orders INT DEFAULT 0 );订单表是整个系统的核心，状态字段的设计会直接影响代码逻辑。我建议增加一个订单编号字段，业务上所有订单详情页都用订单号展示，而不是直接把自增主键暴露给用户。下单时同时记录预估金额和实付金额，方便后面做数据统计。
CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id INT NOT NULL, driver_id INT, start_addr VARCHAR(100), end_addr VARCHAR(100), start_lng DOUBLE, start_lat DOUBLE, status TINYINT DEFAULT 0 COMMENT '0-待接单 1-已接单 2-服务中 3-待支付 4-已完成 5-已取消', estimate_amount DECIMAL(10,2), real_amount DECIMAL(10,2), distance DOUBLE, create_time DATETIME, accept_time DATETIME, finish_time DATETIME );字段里的start_lng和start_lat是用来存上车点经纬度的。真实代驾系统会接地图API，但毕设项目通常拿不到合规的商用Key，我的做法是存好坐标，用静态地图图片加定位标记做演示，效果依然直观。
2.2 订单状态机与数据流转
状态机是这个项目里最值得画进论文的一页图，也是答辩时老师必问的点。订单从创建到完成，状态只允许按固定方向流转：
0（待接单） → 1（已接单） → 2（服务中） → 3（待支付） → 4（已完成）
0（待接单） → 5（已取消）
状态流转的代码要放在Service层统一控制，不能在Controller里到处改状态。比如取消订单这个操作，如果订单已经处于服务中或待支付状态，就不能允许随便取消，必须在updateOrderStatus方法里先做校验。用SQL层面再加一道限制会更稳，例如执行更新时把期望的当前状态作为条件：
UPDATE t_order SET status = 5 WHERE id = #{orderId} AND status = 0这样做的好处在于，即使并发情况下有两个请求同时操作同一个订单，也只有一个能更新成功，后续代码再根据受影响行数判断业务是否执行成功即可。
2.3 金额计算与结算逻辑
代驾收费不是简单的一口价，通常包含起步价、里程费和时长费三部分。毕设里可以把计价规则做成一张价格配置表，也可以直接写在Service层。我更推荐前一种做法，因为答辩时你可以顺带讲一句“价格配置做到了可维护性”。
启动价可以设为38元含10公里，超出部分按每公里3.5元计费，等待时间每分钟0.5元。实际里程在司机点击“结束服务”时由前端传入一个预计里程数，真实系统是GPS轨迹计算，但毕设中让司机填写或者从测试数据里读取都可以接受。结算后的金额写入real_amount字段，同时把订单状态置为“待支付”。乘客端点击支付后修改状态并减少模拟余额，支付这块不需要对接真实支付接口，用一张充值表加余额扣减就能把闭环走通。
3. 核心功能实现与页面细节
3.1 登录权限控制：拦截器 + Session
代驾系统有三种角色，登录后必须区分权限。最简单的方案是在用户表里放type字段，登录成功后把用户对象和角色类型放进Session。然后再写一个拦截器，统一拦截未登录请求。
这里有一点必须注意：拦截要排除登录页、注册页和静态资源。很多同学在调试时出现“页面没样式”或者“登录成功后一直跳回登录页”，十有八九就是拦截器把资源请求也拦了。
<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/register"/> <mvc:exclude-mapping path="/static/**"/> <bean class="com.example.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>拦截器里的判断逻辑很简单，重点是对Ajax请求和普通页面请求分别处理。如果用户登录状态失效但页面还在，普通页面请求直接重定向到登录页没问题，Ajax请求如果也这么干，前端拿到的是一段HTML而不是预期的JSON，就会解析报错。
@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object loginUser = request.getSession().getAttribute("loginUser"); if (loginUser == null) { String xrw = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(xrw)) { response.setStatus(401); } else { response.sendRedirect(request.getContextPath() + "/login"); } return false; } return true; }前端统一封装Ajax时，在回调里判断HTTP状态码，如果等于401就跳转登录页并提示“登录过期”。这套逻辑做完，权限问题基本就稳了。
3.2 司机接单链路：Controller-Service-Mapper
司机接单是整个系统最核心的交互。页面上司机点击“接单”按钮，会同时面临一个经典问题：多个司机抢同一个订单怎么办。如果代码是“先查询订单状态，再判断是否为空，最后更新订单”，那一瞬间的并发会把脏数据写进去。
我的实现方式是把“判断状态 + 抢占订单”合在一条SQL里完成，利用受影响行数来判断是否抢单成功。
@Controller @RequestMapping("/order") public class OrderController { @Resource private OrderService orderService; @ResponseBody @RequestMapping("/accept") public Result accept(Integer orderId, HttpSession session) { Integer driverId = (Integer) session.getAttribute("driverId"); if (driverId == null) { return Result.fail("请先登录司机账号"); } int rows = orderService.acceptOrder(orderId, driverId); if (rows == 0) { return Result.fail("手慢了，订单已被抢"); } return Result.ok(); } }Service层加上@Transactional，保证更新订单和更新司机状态在同一次事务里提交。
@Transactional public int acceptOrder(Integer orderId, Integer driverId) { int rows = orderMapper.acceptOrder(orderId, driverId); if (rows > 0) { driverMapper.increaseOrderCount(driverId); } return rows; }对应Mapper里的SQL是关键，status = 0 AND driver_id IS NULL这两个条件缺一不可。
<update id="acceptOrder"> UPDATE t_order SET driver_id = #{driverId}, status = 1, accept_time = NOW() WHERE id = #{orderId} AND status = 0 AND driver_id IS NULL </update>两个司机同时执行这条SQL时，数据库的行锁会保证只有一个更新成功。失败的请求返回受影响行数为0，前端提示“手慢了，订单已被抢”。这个问题在答辩时非常加分，因为它体现了对并发场景的思考。
3.3 个人信息展示页面与图片坐标定位技巧
JSP项目里最常见的页面就是列表加详情，尤其是司机和用户的个人信息展示。比如司机工作台首页要把司机姓名、电话、车牌号、累计接单数展示出来，用JSTL标签配合EL表达式最直接。查询数据时DriverMapper返回一个DriverVO，里面把用户表的字段和司机表字段都封装好，页面直接用${driver.name}拿值。
<div class="info-card"> <p>司机姓名：${driver.name}</p> <p>手机号码：${driver.phone}</p> <p>车牌号码：${driver.carNo}</p> <p>累计接单：${driver.totalOrders} 单</p> <p>服务状态： <c:choose> <c:when test="${driver.status == 1}">接单中</c:when> <c:otherwise>已休息</c:otherwise> </c:choose> </p> </div>关于“图片如何对坐标定位”这个问题，JSP本身只是一个服务端模板，真正负责定位的是CSS和JavaScript。在代驾系统里，我常用静态地图加定位点来模拟实时位置，因为毕设场景下直接展示一张带标记的示意图，比接入复杂地图SDK更可控。
<div class="map-box" style="position: relative; width: 800px; height: 500px;"> <img src="${pageContext.request.contextPath}/static/img/map_bg.jpg" style="width: 800px; height: 500px;"> <span class="map-point" style="position: absolute; left: 35%; top: 60%; color: #f00;">上车点</span> </div>这里面left和top写的是百分比坐标，好处是图片等比缩放时定位点不会跑偏。如果你要做更复杂的头像裁剪或地图拖拽选点，建议用JavaScript拿到鼠标的偏移量，再算成百分比存进start_lng和start_lat字段。这套逻辑很好扩展，既满足功能要求，又能体现你理解前端定位原理。
3.4 前端 Ajax 与 JSP 模板配合
JSP页面虽然服务端渲染，但不代表不能做异步刷新。乘客下单页需要根据起终点实时显示预估价格，这个必须用Ajax实现。常规做法是写一个/order/estimate接口，接收起点、终点、里程参数，返回JSON格式的金额，前端拿到后直接更新页面。
另一个典型场景是司机端等待新订单。毕设不要求上WebSocket，最简单的方案是写一个定时轮询，每5秒请求一次“获取待接单列表接口”，有新订单就刷新表格。这个方案虽然和真实生产环境有差距，但用于演示业务逻辑足够，答辩时如果你能主动说出“生产环境应该用WebSocket推送”，老师会觉得你有延伸思考。
这里我再提一个细节：如果要在系统里嵌入一段“平台使用演示视频”，一定有人会问“JSP能不能播放MP4”。答案是能。JSP最终输出的是HTML，你用原生HTML5的video标签指定视频路径即可。视频文件放在webapp/static/video/目录下，src指向${pageContext.request.contextPath}/static/video/demo.mp4，浏览器会自动识别并播放。不用在JSP里做任何特殊处理。
4. 部署调试与源码改造注意事项
4.1 IDEA 导入工程与 Tomcat 配置
很多同学拿到源码第一步就卡在环境上。我建议按下面这个顺序操作，基本不会踩坑：
- 安装JDK1.8，并确认环境变量配置正确。在命令行执行
java -version能正常输出版本号即可。 - 安装Maven，并在IDEA里将Maven设置为本地安装版本，不要用IDEA内置的Maven，否则依赖路径经常对不上。
- 新建或导入项目时选择Maven项目，等待依赖全部下载完成。
- 在
src/main/resources中找到数据库配置文件，修改MySQL地址、用户名、密码。 - 执行项目附带的
init.sql脚本，初始化数据库。 - 配置Tomcat，在Deployment里添加
war exploded包，Application context设置为/。 - 把Tomcat的JDK版本调整到1.8，然后启动。
数据库驱动依赖的写法已经固定，不需要改动，但要注意MySQL版本。如果是MySQL 5.7，驱动类用com.mysql.jdbc.Driver；如果是MySQL 8.x，驱动类用com.mysql.cj.jdbc.Driver，同时连接串里要加serverTimezone=Asia/Shanghai，否则会报时区错误。
jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/driver_service?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=1234564.2 MyBatis 常见报错排查
下面这张表整理了我这几年看到的高频问题，直接对照排查要比网上零散搜答案高效得多：
| 报错现象 | 常见原因 | 解决思路 |
|---|---|---|
| Invalid bound statement (not found) | Mapper接口与XML文件不对应 | 检查XML的namespace是否等于接口全限定名，方法id与接口方法名是否一致 |
| Mapped Statements collection already contains value | XML里的id重复或同名 | 检查MapperXML方法id，避免重载方法名一致却没有区分 |
| TooManyResultsException | 查询返回多行，但方法用单个对象接收 | 确认SQL条件是否漏了主键，或改用List接收 |
| 页面报404但控制台没错误 | 请求路径和Controller映射不一致 | 检查@RequestMapping值，以及前端请求路径是否带了项目上下文 |
| 中文乱码 | 数据库连接串没指定编码 | 在jdbc.url中确保characterEncoding=utf8，页面顶部加pageEncoding="UTF-8" |
4.3 登录安全、SQL 注入与密码处理
用MyBatis有个天然优势：只要写SQL时坚持用#{}而不是${}，就能有效避免SQL注入。#{}会被编译成?占位符，由数据库驱动做参数化处理；${}是字符串拼接，用户输入如果带了特殊内容，很可能直接拼进SQL，这是绝对要避免的。
密码存储也不要明文入库。毕设里用MD5加盐就够了，比如用户注册时把password + fixedSalt拼起来再做一次MD5，登录时对用户输入做同样处理再和数据库比对。更容易被忽略的是密码加密不能只做一次，建议循环执行两次，或者直接使用更安全的摘要算法，论文的安全性章节能有内容可写。
另外提醒一个容易忽略的问题：如果后台管理页面的删除操作用的是GET请求，浏览器地址栏直接访问就能删数据。所有涉及状态修改和删除的接口，尽量改成POST提交，再配合拦截器做权限校验，这个细节能让源码质量上一个档次。
4.4 源码交付清单
毕设源码交付不是随便压缩一个文件夹就完事，我习惯整理成这样：
src目录：Java源码、MapperXML、配置文件、静态资源sql目录：数据库初始化脚本，SQL脚本里要带上创建数据库的语句，保证任何同学拿到都能一键执行README.md：写清楚运行步骤、初始账号密码、JDK和Tomcat版本要求docs目录：数据库设计说明、核心接口说明，方便写论文时直接参考
很多同学最后栽在“换了一台电脑就跑不起来”这件事上，原因就是初始化脚本没给全。请务必把测试账号写进README，比如管理员账号、乘客账号、司机账号各准备一个，演示和审查都会省很多时间。
5. 答辩演示与扩展建议
5.1 演示路径设计
毕业设计答辩时间通常不超过10分钟，演示不能从头到尾点一遍菜单。我的建议是按“用户下单、司机接单、后台看单”这三幕来演示，每一幕只讲一个核心亮点。
第一幕演示乘客端，重点展示登录注册和代驾下单，下单时输入起终点，实时显示预估价格，提交后订单状态变为“待接单”。第二幕切换到司机端，点击接单成功，然后把订单状态从“已接单”改到“服务中”，再改到“待支付”，乘客端这时候同步看到里程和实付金额，最后点支付完成。第三幕打开后台订单管理，筛选出刚才那笔订单，展示订单明细和统计数字，形成完整闭环。
演示数据最好提前准备：司机账号处于“接单中”状态，乘客账号余额充足，待接单列表里有几条构造好的数据。不要在答辩现场临时注册用户，一旦用户名重复或接口报错，会打乱整个宣讲节奏。
5.2 老师常问的问题怎么答
根据我陪同学模拟答辩的经验，点评老师最关心的通常就这几个问题：
第一个是“为什么选JSP而不选前后端分离”。不要答“因为题目要求”，要说清楚SSM+JSP是单体架构里的经典组合，所有请求在服务端渲染，适合快速验证业务流程，也便于从零学习框架协作方式。
第二个是“多个司机同时抢一单怎么处理”。把3.2里的那条SQL逻辑讲清楚，强调“更新的条件里带上期望状态”是乐观锁思想，即便不引入Redis分布式锁也可以保证数据一致。
第三个是“订单金额怎么算”。把起步价、里程费、时长费的计算公式讲清楚，再补充说明真实金额应由GPS轨迹计算得到，毕设里用预估里程模拟。
第四个是“为什么使用MyBatis而不是Hibernate”。可以从SQL可控制性、动态SQL、性能优化空间几个角度来答，这几条都是MyBatis相对Hibernate的实际优势。
第五个是“如果项目发布上线，哪些地方需要改”。回答方向围绕Redis缓存热点数据、WebSocket实时推送订单、HTTPS加密通信、分布式部署下的Session共享。这些问题能接得住，基本就是优秀档次。
5.3 后续扩展方向
这套系统如果还有时间，可以往三个方向扩展。最自然是加实时订单推送，用WebSocket替换轮询，司机端不用刷新页面就能看到新单提醒，演示效果会明显提升。其次是引入缓存，把司机位置、热点区域订单量放进Redis，降低数据库压力。最后是把订单查询做成带分页和条件筛选的组合查询，后台管理会更有真实项目的感觉。
如果想把技术栈升级到Spring Boot，业务逻辑和数据库表可以原封不动地迁移，只要把SSM的XML配置换成自动配置，再把控制层代码调整一下，就能完成一个复用度很高的二次改造。这部分内容甚至可以直接写进论文的“系统展望”章节。
我最后再说一个实操心得：毕业设计项目不要追求功能堆砌，真正重要的是把一条业务链路做通、做稳。代驾系统里“乘客下单、司机抢单、结单支付”这三步能流畅跑通，加上合理的权限控制和良好的代码结构，已经超过大多数同类毕设。我见过太多同学把页面做得花里胡哨，结果核心订单状态一改就报错，那就本末倒置了。把这套SSM+JSP的项目吃透，面试时聊到Java Web、数据库设计和业务建模，你都会有实际案例可以讲，这才是这个题目最大的价值。
