带了三届毕业生做毕设，每年临到5月都能看到同一种表情：代码跑起来了，但论文一个字没写。今年大概率也不会例外，尤其是选“汽车租赁管理系统”这类经典题目的同学——SSM + Java + MySQL，题目看着不难，真要动手才发现每一步都有选择：框架版本用哪个？表怎么建？订单状态怎么设计？是先写代码还是先写论文？
这篇东西把我这些年带SSM项目踩过的坑、总结出来的完整思路捋一遍，从技术选型开始一直聊到答辩现场，核心围绕SSM框架和Java后端开发这条主线，把汽车租赁管理系统从0到1的完整路线给你拆清楚。不管是刚拿到题目的应届生，还是想快速了解SSM项目的同学，都能拿来直接用。
1. 为什么2026年了，我还要劝你选SSM做毕设
1.1 SSM不是三个框架的堆砌，而是三条明确的分工线
很多同学一听到SSM就头大：“Spring、SpringMVC、MyBatis，这么多配置，为什么不用Spring Boot？”说实话，我也理解这种焦虑。但换个角度想就通了：SSM本质上是一套分工极其明确的生产流水线。
我用一个比较接地气的类比来解释。把系统想象成一家租车公司：
- Spring是公司的后勤总管。它负责创建所有员工（Bean）、管理员工之间的协作关系（依赖注入），还负责公司的规章制度（AOP切面，比如日志记录、权限校验这类横切逻辑）。你只管告诉它“我要一个订单Service”，它就把该有的依赖都给你配好。
- SpringMVC是门店前台。用户的所有请求（看车、下单、还车）都由前台接进来，DispatcherServlet就是前台经理，先把请求领进门，再分发给对应的Controller去处理，处理完的页面结果再由视图解析器送回给用户。
- MyBatis是仓库管理员。它管的是数据库里那堆数据——把Java对象映射成SQL语句，再把查询结果映射成Java对象。你在Mapper.xml里写SQL，它负责执行并返回结果。
三个框架各管一摊，链路清晰，边界分明。恰好因为SSM“配置多、需要手动处理的细节多”，你在答辩和面试的时候才有东西可讲。用Spring Boot做毕设的同学，很多时候被问“自动配置原理是什么”就卡住了，但SSM项目的每个配置都是你亲手写进去的，提问基本都能接住。
1.2 SSM依然是高校教学和毕设题目库的稳定选项
这里说一个比较现实的情况：很多学校的Java课程体系还是按“JavaSE基础 → Servlet/JSP → SSM → 高级框架”的顺序排的，毕业设计题目库里像“XX管理系统”这种经典题目，出题模板用的也是SSM。2026年了，SSM还在被大量院校用于教学和毕设，不是因为这些学校落后，而是因为SSM背后的Spring核心思想（IoC容器、AOP、事务管理）不会过时，学透了它，再上手Spring Boot或者其他框架都很轻松。
从导师的角度看，SSM项目的代码结构是透明的。Controller、Service、Mapper层层分明，导师审论文时一眼就能看懂系统架构，这反而省去了很多不必要的沟通成本。从你的角度看，网上的资料、教程、参考项目多到看不完，遇到问题能查到的答案远比用一个小众框架多得多。
1.3 SSM和Spring Boot在毕设场景下的对比
我整理了一张对比表，都是自己带项目时经常给学生说到的点：
| 对比维度 | SSM（Spring + SpringMVC + MyBatis） | Spring Boot |
|---|---|---|
| 入门门槛 | 配置多，前期搭建成本高 | 起步快，配置极少 |
| 框架原理理解深度 | 配置都要自己处理，逼着你搞懂原理 | 自动配置，容易说不清原理 |
| 资料丰富度 | 极多，各类博客、源码、视频都有 | 极多，但偏实战向 |
| 答辩可讲深度 | 可讲点分散在配置、拦截器、事务等细节 | 更多在业务逻辑本身 |
| 与课程衔接 | 直接衔接大多数院校教学路径 | 多数学学校并未深入教学 |
| 找工作的关联性 | 面试常考Spring、MyBatis底层原理 | 企业用的多，但面试照样问底层 |
看完你应该也发现了一个规律：SSM累在前期，但积累的东西在答辩和面试阶段都会还给你。所以我一般情况下都建议没有代码基础、又想做“管理系统”类题目的同学稳住心态选SSM。当然，如果你大学期间已经实习做过Spring Boot项目，那直接基于Boot做也不是不行，关键是别让自己陷入“会遇到一个没见过的报错就卡一天”的被动局面。
1.4 哪种情况不适合选SSM
我说“劝你选SSM”，也不是无脑推。有几类情况其实更适合换思路：
- 选题本身带有明显的前沿性质，比如要求对接小程序、公众号、第三方地图API，那用SSM会增加不少对接工作量，Spring Boot会更顺手。
- 你已经有比较扎实的项目经验，并且时间紧张，想快速把毕设做完，用Spring Boot可以省下大量配置时间。
- 导师明确给了技术栈要求，那就以导师要求为准，不用纠结。
如果只是想在“汽车租赁系统”这个经典题目上安安稳稳做完、顺利答辩、拿到学分，SSM是容错率最高的选择。
2. 功能设计：别急着写代码，先把租车这门生意拆明白
2.1 从线下租车场景反推系统功能
做系统最怕的就是打开IDEA就开始写表、写接口，写到一半发现逻辑对不上。所以第一步应该是回到业务本身。
你想想现实中租车是怎么回事：用户到门店看车，选中一辆，出示身份证和驾驶证，签租赁合同，交押金，拿钥匙走人；用完之后把车开回门店，工作人员验车，计算租金，多退少补，退还押金，订单结束。
这一套业务流程对应到系统里，就是两条清晰的主线：
第一条线：用户租车闭环。用户注册登录 → 浏览车辆 → 选择租期 → 创建订单 → 支付押金租金 → 到店取车 → 使用车辆 → 归还车辆 → 系统结算（含租金、逾期费）→ 订单完成。
第二条线：管理员管车闭环。管理员登录后台 → 录入新车辆 → 设置车辆状态（可租/已租/维修/下线）→ 处理用户订单 → 还车后更新车辆状态 → 查看经营数据。
这两条线画清楚之后，你的功能清单基本就出来了，代码只是把这些动作落地而已。
2.2 MVP功能清单：做到什么程度才算合格
我整理了一个可以直接抄走的MVP（最小可行产品）功能清单：
| 角色 | 功能模块 | 具体功能点 |
|---|---|---|
| 用户 | 注册登录 | 用户名密码注册、登录、退出登录、密码MD5加密存储 |
| 用户 | 车辆浏览 | 车辆列表、按类型筛选、按日租金排序、车辆详情 |
| 用户 | 租车下单 | 选择车辆、选择取车/还车日期、自动计算租金、提交订单 |
| 用户 | 订单管理 | 查看我的订单、模拟支付、取消订单（未取车前） |
| 用户 | 个人中心 | 查看个人信息、修改联系方式、查看历史订单 |
| 管理员 | 后台登录 | 独立后台入口，管理员身份校验 |
| 管理员 | 车辆管理 | 添加车辆、编辑车辆信息、上下架车辆、维护车辆状态 |
| 管理员 | 订单管理 | 查看所有订单、按状态筛选、确认出车、结算订单 |
| 管理员 | 用户管理 | 查看用户列表、冻结/解冻用户 |
| 管理员 | 基础数据 | 车辆类型管理（轿车、SUV、商务、新能源） |
这些功能做完，系统已经是一个完整可用的租车平台。别小看这个清单，很多偷懒的网上项目连“取消订单”“车辆状态维护”都没有，答辩时被导师一追问就露馅。
2.3 加分项怎么做才能“分得实在”
MVP能保证你及格，但想拿优秀，就得在功能上做深度而不是广度。我见过太多同学试图把系统做成“管理全家桶”——车辆模块、新闻模块、留言板模块、积分模块全塞进去，结果每个模块都只写了两张表，逻辑糊成一片。
我的建议是只挑两个点往深里做：
一个做订单状态机。把订单的生命周期拆成“待支付 → 已支付待取车 → 租赁中 → 待结算 → 已完成 / 已取消 / 已退款”，每个状态之间的流转条件都写清楚，支付和退款做模拟实现。这一个点做好了，导师会觉得你理解了业务本质。
另一个做费用结算逻辑。日租金、押金、逾期费、车辆损坏赔偿，这些费用怎么算、由谁算、在哪一步算，把规则写死，界面展示每一笔费用的明细。这两个亮点足以让你的系统和网上一抓一大把的“半成品”拉开差距。
2.4 网上源码的坑：功能看着全，逻辑一团乱
每年都有人直接从网上下载一个开源租车系统改改就交差。我要说句得罪人的实话：大多数你能下载到的“毕设源码”，恰恰是毕设质量的灾难。
一是普遍使用魔法数字，订单状态散落在代码各个角落，一个if一个状态，改起来牵一发动全身；二是数据库设计随意，能查出来数据就行，索引、约束一概没有；三是注释和文档故意写得很大，但业务逻辑很浅。
你要是参考它们的思路可以，但千万别照抄。尤其不要直接用它们做好的MySQL脚本，那里面如果有个字段吃不准是什么意思，到答辩的时候就是一颗雷。
3. 数据库设计：这个系统的地基到底怎么打
3.1 核心表清单与字段规划
系统的所有业务逻辑最终都落在数据库上。汽车租赁系统最精简也需要6张表：
| 表名 | 中文名 | 核心字段 |
|---|---|---|
| user | 用户表 | id, username, password, real_name, phone, id_card, driver_license, create_time |
| admin | 管理员表 | id, username, password, role |
| car | 车辆表 | id, brand, model, plate_no, type_id, store_id, daily_rent, deposit, status, image, description |
| car_type | 车辆类型表 | id, type_name |
| store | 门店表 | id, store_name, address, phone |
| orders | 订单表 | id, order_no, user_id, car_id, pickup_date, return_date, actual_return_time, daily_rate, deposit, rental_days, total_rent, overdue_fee, status, pay_status, create_time |
这个表结构不是凭空拍的，它覆盖了前面说的两条业务闭环。所有字段加起来，足够支撑完整功能，又不会让系统臃肿到后期维护成本太高。
3.2 车辆表的灵魂字段：status
车辆表里最容易被忽视、实际最核心的字段就是status。它是车辆状态的实时标签，直接决定这辆车能不能被用户搜索到、能不能下单。
我常用的设计是这样：
| 状态值 | 含义 | 业务限制 |
|---|---|---|
| 0 | 可租 | 用户可浏览、可下单 |
| 1 | 已租出 | 不可下单，等还车后恢复 |
| 2 | 维修中 | 管理端标记，前端不展示 |
| 3 | 已下线 | 管理员主动下架，前端不展示 |
很多学生喜欢用字符串存状态，比如“在租”“空闲”，这也能跑得通，但用整数枚举值更规范，也更容易扩展。注意一个细节：车辆状态和订单状态必须联动，人家下单成功车辆就该变成“已租出”，还车结算之后才能恢复成“可租”。这个联动逻辑写在Service层，千万别在Controller里到处乱改状态。
3.3 订单表的设计逻辑：快照、金额拆分与时间计算
订单表是整个系统里设计难度最高的一张表，也是答辩时最容易被追问的表。三个细节必须想明白：
第一个细节是快照字段。想象一下：用户下单的时候，这辆车的日租金是200元；三个月后管理员把租金调到了300元，此时再看历史订单，到底按哪个价格算？正确答案是按下单时的价格。所以在订单表里要冗余一份daily_rate字段，直接把下单那一刻的价格快照存进去。同理，车辆的品牌型号也建议在订单里存一份快照，否则管理员改了车辆信息，历史订单显示的内容就会跟着变，打印合同时就对不上了。
第二个细节是金额拆分。订单涉及的费用分三类：押金（可退）、租金（必收）、逾期费（可能为0）。这三笔钱要分字段存，不能混在一起。我建议至少保留deposit、total_rent、overdue_fee三个字段，结算页面分别展示，一目了然。
第三个细节是时间字段与租金天数计算。租车天数不是简单减一下就行。我用一个最多的情况举例：用户周一下午3点取车，周四上午10点还车，这种跨天不足时怎么算？常规做法是ceil((还车时间 - 取车时间) / 一天毫秒数)，向上取整，即不足一天按一天算。还有的规则是首日按小时计费、超过4小时算一天，这种属于业务细节，你可以写在论文的“收费规则”里。但无论怎么定，规则必须清晰，代码里要有明确的注释说明计算方式。
// 租金天数计算：向上取整，不足一天按一天算 long mills = returnDate.getTime() - pickupDate.getTime(); int days = (int) Math.ceil(mills / (24.0 * 60 * 60 * 1000)); BigDecimal totalRent = dailyRate.multiply(BigDecimal.valueOf(days));3.4 外键到底用不用？我的建议是逻辑外键
很多教程让你老老实实加FOREIGN KEY，但真实项目里有个反直觉的实践：物理外键尽量少用。汽车租赁系统的核心表是订单表，高频增删改，每一次写入都要校验外键约束，数据库压力大不说，还容易因为约束问题引发死锁。更常见的问题是有时候你想删除一辆车，但它在订单表里还有关联记录，物理外键会直接拦着你删不掉。
我推荐的做法是“逻辑外键”：表与表之间靠字段关联（比如orders.car_id指向car.id），但不建立 FOREIGN KEY 约束。这样既能在Java代码里拿到关联数据进行业务编排，又避免数据库层面的强耦合。这个理解决议答辩时说出来，是实打实的经验分。
3.5 索引设计：提前把慢查询按死在摇篮里
数据量不大时索引确实无所谓，但毕设论文里“系统性能设计”这一节总要写点什么。我的建议很朴素：
user.username加唯一索引，保证注册不重名。orders.order_no加唯一索引，这个必须唯一。orders.user_id加普通索引，因为“我的订单”要频繁按用户查。orders.status加普通索引，管理员按状态筛选订单时会用到。car.status加普通索引，前端车辆列表大概率会按状态过滤。
索引不是越多越好，写多了一点技术含量没有，还可能拖慢插入速度。上面这5个就是刚刚好。
4. 从登录到还车：核心业务链路编码实现与避坑
4.1 后端包结构：一开始就分层，后面省一万个心
代码写多了你会发现，SSM项目里包结构就是系统的骨架，骨架歪了后面全乱。我一般建议按这种分包方式：
com.rent ├── controller // SpringMVC控制层，接收请求，返回视图 ├── service // 业务逻辑层，事务边界都在这层 │ └── impl ├── mapper // MyBatis的Mapper接口 ├── entity // 数据库实体类 ├── interceptor // 登录拦截器等 ├── common // 通用返回结果、常量、枚举、工具类 └── config // Spring配置相关（也可以用XML）这个结构其实和SSM经典的三层架构一一对应：Controller是表现层、Service是业务层、Mapper是数据访问层。每一层只能调用下一层，不能跨层调用。以后写论文画系统架构图，也是照着这个分层画。
4.2 登录鉴权与拦截器配置：最容易翻车的地方
登录功能看似简单，但有两个高频翻车点。
第一个翻车点是拦截器没放行静态资源。你写了个后台管理页面，CSS和JS全部加载不出来，原因就是拦截器把所有请求都拦了，静态资源被挡在门外。所以SpringMVC的XML配置里必须显式放行/static/**。
<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <!-- 登录和注册接口必须放行 --> <mvc:exclude-mapping path="/user/login"/> <mvc:exclude-mapping path="/user/register"/> <!-- 静态资源必须放行 --> <mvc:exclude-mapping path="/static/**"/> <bean class="com.rent.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>第二个翻车点是登录状态保存位置。放在Session里是最简单可靠的做法，登录成功后执行：
session.setAttribute("loginUser", user);拦截器里取出来判断：
public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { // 没登录就跳回登录页，注意要带上contextPath response.sendRedirect(request.getContextPath() + "/user/login"); return false; } return true; } }这里有个细节：如果你是“用户端”和“管理端”两套入口，建议用两个拦截器或者用Session里的角色字段区分，别把管理员和普通用户混在一个Session里，容易出现越权操作的逻辑漏洞。
4.3 车辆多条件查询与分页：POI级别的动态SQL小技巧
车辆列表页一般都有筛选功能：按类型、按关键字、按品牌。如果给每种情况都写一条SQL，Mapper里会变成灾难。正确的姿势是用MyBatis的动态SQL，一个方法搞定所有筛选组合。
<select id="searchCars" resultType="com.rent.entity.Car"> SELECT * FROM car <where> <if test="typeId != null"> AND type_id = #{typeId} </if> <if test="keyword != null and keyword != ''"> AND (brand LIKE CONCAT('%', #{keyword}, '%') OR model LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select>分页我直接建议用PageHelper插件，引入依赖后在Service里这样写：
PageHelper.startPage(pageNum, pageSize); List<Car> carList = carMapper.searchCars(condition); PageInfo<Car> pageInfo = new PageInfo<>(carList);PageInfo里已经封装好了总条数、总页数、当前页这些参数，前端渲染分页条的时候直接取就行，不用自己写任何SQL分页逻辑。答辩时如果被问到分页实现原理，你就说“基于MyBatis的拦截器机制，在执行SQL前自动拼接LIMIT语句”，这句话很加印象分。
4.4 订单状态机的编码实现：用枚举替代魔法数字
订单状态是整个系统最核心的难点，我前面提过要把它做深。这里说具体做法：先在common包下建一个枚举类，把状态都定义好，不要到处写if (status == 1)这种魔法数字。
public enum OrderStatus { PENDING_PAYMENT(0, "待支付"), PAID(1, "已支付待取车"), RENTING(2, "租赁中"), PENDING_SETTLE(3, "待结算"), COMPLETED(4, "已完成"), CANCELLED(5, "已取消"), REFUNDED(6, "已退款"); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code = code; this.desc = desc; } public int getCode() { return code; } public String getDesc() { return desc; } }状态流转的规则我建议全部集中在Service层的一个方法里，并写好注释，比如：
- 待支付 → 已支付：用户点击支付，更新
pay_status - 已支付 → 租赁中：管理员点击“确认出车”，车辆状态同步改为“已租出”
- 租赁中 → 待结算：用户点击“我要还车”，记录实际还车时间，计算费用
- 待结算 → 已完成：管理员结算完成后，订单关闭，车辆状态恢复为“可租”
- 待支付 → 已取消：用户取消或者支付超时，可退款处理
把这一步做扎实，答辩时你就有了自己的“业务亮点”。
4.5 两个高频踩坑实测
第一个坑是@Transactional事务失效。很多同学在Service的实现类里写了一个带事务的方法，内部调用另一个不带事务的方法，结果发现报错后数据照样写进去了。原因是Spring事务是基于AOP代理实现的，同类内部调用走的是this引用而不是代理对象，事务注解就失效了。解决办法是把需要事务保护的逻辑拆到另一个Service中，或者注入自身代理：
@Service public class OrderServiceImpl implements OrderService { @Autowired private OrderService self; // 注入自身代理 @Transactional public void createOrder(OrderDTO dto) { // 扣减库存/生成订单等操作 self.deductStock(dto.getCarId()); } }第二个坑是金额计算用double。租金、押金、逾期费只要涉及钱，一律用BigDecimal，别用double。你去算一下0.1 + 0.2，用double会得到0.30000000000000004，这类浮点误差在论文测试章节是致命伤。
BigDecimal dailyRate = new BigDecimal("200.00"); BigDecimal days = BigDecimal.valueOf(3); BigDecimal totalRent = dailyRate.multiply(days); // 600.00数据库里对应字段也用DECIMAL(10,2)，Java实体用BigDecimal类型，这条链路从底到顶保持一致。
4.6 SSM常用注解速查：答辩会问的都在这里
我在辅导学生时发现，很多人代码能跑通，但问他“@Controller和@RestController什么区别”就卡壳。这里整理一份SSM开发中最常用的注解清单，保证你答辩时被问“用到了哪些注解”不会冷场：
| 注解 | 作用 | 使用位置 |
|---|---|---|
| @Controller | 声明控制器，返回视图名 | Controller类上 |
| @ResponseBody | 方法返回值直接写入响应体，不走视图解析器 | Controller方法上 |
| @RestController | @Controller + @ResponseBody 的组合 | Controller类上 |
| @RequestMapping | 映射请求URL（类/方法级别） | Controller类/方法上 |
| @RequestParam | 绑定单个请求参数 | Controller方法参数上 |
| @PathVariable | 绑定URL路径参数 | Controller方法参数上 |
| @Autowired | 按类型自动注入依赖 | 字段/构造器/Setter上 |
| @Service | 声明业务层组件 | Service实现类上 |
| @Repository | 声明数据访问层组件 | Mapper接口实现类上 |
| @Transactional | 开启数据库事务 | Service方法/类上 |
| @Param | 给Mapper接口参数命名，对应XML中的#{param} | Mapper接口方法参数上 |
| @DateTimeFormat | 格式化前端传入的日期参数 | 实体字段/方法参数上 |
这套注解理解透了，不光论文的技术介绍章节好写，将来面试问Spring相关内容你也不怵。
5. 论文写作：把代码翻译成导师看得懂的成果
5.1 论文目录骨架与写作顺序
代码做得再漂亮，论文写不出来照样白搭。汽车租赁管理系统这类论文基本是固定套路，目录骨架建议这样搭：
第1章 绪论（选题背景、研究意义、国内外现状、研究内容） 第2章 相关技术介绍（Java、SSM框架、MySQL、前端技术） 第3章 需求分析（可行性分析、功能需求、非功能需求） 第4章 系统设计（总体架构、功能模块设计、数据库设计） 第5章 系统实现（每个模块的界面、核心代码与说明） 第6章 系统测试（测试环境、测试用例、测试结论） 第7章 总结与展望 参考文献 致谢我不建议按章节顺序从第1章写到第7章。最合理的顺序是：先把第2章和第3章写了，因为这两章不依赖代码，大部分内容是参考书籍和网上的资料就能组织出来的。等代码完成后再写第4、5章，因为这两章需要截图和核心代码，是“你实际做了什么事”的直接体现。摘要永远最后写，写摘要的时候你对整篇论文做了什么心里已经完全有数了。
5.2 需求分析和用例图怎么画
需求分析主要的产出物是用例图和用例描述。用例图用ProcessOn或者draw.io画，简单快捷，别去安装那些重型建模工具。汽车租赁系统的用例图就两个角色：
- 用户：注册、登录、浏览车辆、租车下单、支付押金、还车、查看订单、修改个人信息。
- 管理员：登录、车辆管理（增删改查、上下架）、订单管理（查看、审核、结算）、用户管理。
论文里不要只丢一张图，每个用例后面最好配一段“用例描述”，写清楚参与者、前置条件、基本流程、异常流程。导师翻论文时看到这部分内容，会认为你的需求分析是完整的，而不是随手画个图凑字数。
5.3 核心代码讲解的写法：别贴一百行，挑关键的十行
第5章系统实现，最容易犯的毛病是把所有Controller代码一股脑贴进去，凑了一堆篇幅，导师却看得昏昏欲睡。这里的正确写法是“截图 + 核心方法片段 + 文字解释”三件套。
以“创建订单”为例：
- 截一张创建订单页面的图，让导师知道这个功能长什么样。
- 贴出Service层创建订单核心方法的片段，控制在20行以内。
- 用两三段话解释这段代码做了什么，比如“本方法先校验车辆状态，只有可租状态的车辆才能下单；然后根据用户提交的取车时间和还车时间计算租车天数与租金，并生成唯一订单号；最后将订单状态置为待支付状态”。
这样写出来的论文，一看就是“做过之后才写得出来的描述”，而不是“照着别人的代码改的”。
5.4 测试章节的用例表写法
系统测试章节最实用的形式是写一组测试用例表。我给出一个可以直接套用的格式：
| 用例编号 | 测试项目 | 操作步骤 | 预期结果 | 实际结果 | 是否通过 |
|---|---|---|---|---|---|
| TC001 | 用户登录 | 输入正确用户名密码 | 登录成功并跳转首页 | 登录成功 | 通过 |
| TC002 | 用户登录 | 输入错误密码 | 提示密码错误 | 提示密码错误 | 通过 |
| TC003 | 车辆查询 | 按类型选择“SUV” | 仅显示SUV类型车辆 | 正常显示 | 通过 |
| TC004 | 租车下单 | 选择租期并提交 | 生成待支付订单，租金计算正确 | 生成订单，金额正确 | 通过 |
| TC005 | 超期还车 | 超出还车日期1天 | 自动计算逾期费 | 逾期费=日租金×1.5 | 通过 |
| TC006 | 取消订单 | 待支付状态下取消 | 订单状态变为已取消 | 显示已取消 | 通过 |
测试用例不需要太多，10到15个就够，但覆盖的场景要全：正常流程、异常流程、边界值各占三分之一。这种表格写进论文，整章的含金量立刻上来。
6. 答辩前夜的三个准备动作与高频问题应对
6.1 第一件事：把SSM请求流程画下来并背熟
答辩提问基本逃不开框架层面，而SSM最经典的问题就是“一次用户请求是怎么被处理的”。这个问题答好了，第一印象分就有了。标准回答流程是：
浏览器发送请求 → SpringMVC的DispatcherServlet（前端控制器）接收 → 通过HandlerMapping找到对应的Controller方法 → Controller调用Service层处理业务逻辑 → Service调用Mapper（MyBatis）操作数据库 → 结果逐层返回 → DispatcherServlet通过ViewResolver解析视图 → 返回给浏览器渲染。
这段逻辑你不仅要会写，还要能不看稿子说出来。我建议在答辩前一晚上，找张白纸把这个流程画几遍，直到能条件反射一样脱口而出。如果被追问“DispatcherServlet是怎么初始化出来的”，你能答出“它是在web.xml中配置的，容器启动时由Spring创建并注册”就已经在正确的路上了。
6.2 第二件事：准备一套6分钟演示脚本
答辩现场时间有限，千万别打开项目后从首页一个个点给你看。提前想好演示顺序，挑核心链路走，每一分钟都不能浪费。我建议的演示脚本是这样：
- 演示用户注册登录，让导师看到登录后Session生效、页面右上角用户名变化。
- 演示车辆列表页，现场按类型筛选一次，展示动态SQL查询效果。
- 演示租车下单，选一辆车、选租期、提交订单、模拟支付，重点点出订单号生成和金额计算。
- 切到管理端，演示订单“确认出车”，让导师看到车辆状态变为“已租出”。
- 模拟还车，演示费用结算明细（租金、押金、逾期费）。
- 最后切回数据库，打开orders表，指出刚才那条订单已经完成了状态更新。
整个过程不要超过6分钟，控制在3-4分钟更稳。给导师留出提问时间，比被催着“讲快点”体面得多。
6.3 高频答辩问题清单：框架原理、数据库、业务逻辑三类
我整理了这些年带毕设被问到的高频问题，按三类分好，都附带简要的应答思路：
| 类型 | 高频问题 | 应答思路关键词 |
|---|---|---|
| 框架 | Spring中Bean的生命周期 | 实例化 → 属性注入 → 初始化 → 使用 → 销毁 |
| 框架 | AOP在项目里怎么用的 | 事务管理、日志记录、登录校验 |
| 框架 | MyBatis中#{}和${}有什么区别 | #{}预编译防SQL注入，${}是字符串拼接 |
| 框架 | 为什么用MyBatis不用JDBC | 自动映射结果集、动态SQL、代码量与维护成本 |
| 数据库 | 车辆表和订单表是什么关系 | 一对多，一辆车对应多条订单记录 |
| 数据库 | 订单表为什么存冗余字段 | 历史快照，防止车辆信息或价格变更影响历史订单 |
| 业务 | 租金和押金怎么计算的 | 日租金×天数向上取整；押金按车辆价值定，可退 |
| 业务 | 用户取消订单后押金怎么处理 | 待支付状态取消不涉及退款；已支付需走退款流程 |
| 业务 | 车辆被下单了还能重复下单吗 | 不行，下单时校验车辆状态，并发场景建议加锁 |
这些问题你提前准备过，和临场硬编是完全两种状态。
6.4 第三件事：快速补齐面试级知识点
答辩本质上就是一场简化版的技术面试。如果你时间紧张，优先补三个点：
第一个是Spring的IoC和AOP。
IoC就是控制反转，把对象的创建和依赖管理交给Spring容器，好处是解耦和可维护性高。AOP是面向切面编程，把日志、事务这类横切逻辑从业务代码里抽出来，在运行期通过动态代理织入。这两个概念你至少要能各说两个句话，结合项目举例。
第二个是MyBatis的一级缓存与二级缓存。
一级缓存是SqlSession级别的，同一个SqlSession中执行相同查询，第二次会命中缓存，默认开启。二级缓存是namespace级别，需要手动开启。答辩问到这个的概率不低，因为你的项目中确实用了MyBatis，导师完全有理由深挖。
第三个是MySQL索引为什么查询快。
核心就是B+树的数据结构——数据按序存储，查询时通过二分查找快速定位，时间复杂度从全表扫描的O(n)降到O(log n)。你不用讲得多深，但至少要能说出“索引是B+树结构，数据库查询时先走索引再回表”这层意思。
这三个点不光答辩有用，你毕业找工作时这些就是Java后端面试的入门题，现在补上不亏。
最后说点心里话
带这么多届学生做毕设，我最深的体会是：文档写不出来，往往不是写作能力的问题，而是代码本身没想清楚。代码写明白了，论文就是把做过的事情复述一遍；代码含糊，论文再挤也挤不出有营养的东西。
所以我自己的建议一直很固定：每完成一个模块，就顺手把对应的论文小节写掉，别攒到最后。这样写出来的文字是“复述自己做过的事”，而不是“编造一个自己没做过的系统”。等整个系统全部跑通后，再抽出半天时间，把注册、登录、下单、支付、还车、结算这条链路从头完整走两遍，手动构造几个边界场景——比如还车时间卡在零点、连续租两天、账户余额不足、超期还车。把每一步的画面和数据库变化截图存档。这些素材，写论文测试章节也好，答辩演示也罢，关键时刻都是最实在的底气。
祝你的2026年毕设顺利收官。
