又到了一年毕业设计的高峰期，管理群和问答社区里最常看到的问题就是——“有没有现成的交通违章管理系统代码？”说实话，这个题几乎年年都有，但每年交上来的东西质量参差不齐。少数同学是真的把业务逻辑搞明白了，大部分只是把增删改查套了个外壳，答辩的时候经不起追问。我自己帮人指导过好几套类似的课设和毕设，也亲手从零做过一个基于JavaEE的交通违章处理系统，完整的代码、数据库脚本、说明文档和LW（论文）都整理过。
这篇不打算搞那种“复制粘贴就能过”的馊饭，而是把整个系统从选择题目、划分功能、设计数据库、写前后端代码，到整理文档和应对答辩调试的完整链路拆开来讲。只要你照着这个思路走，哪怕代码基础一般，也能把这个题做得明明白白，而且你在答辩时能说出个一二三来，而不是背稿。
1. 毕设题目的真实含义与选型思路
1.1 “JavaEE”到底指什么，怎么选框架才不踩坑
先解决一个最让人纠结的问题：题目里写的是“JavaEE”，但JavaEE这个名词本身就挺模糊。早期的JavaEE(就是J2EE)特指Servlet、JSP、EJB那一整套重量级规范，写起来各种XML配置，让人头大。现在你要是真的用EJB去做一个毕设，不仅代码量爆炸，而且能参考的资料少之又少。
我的建议是：把“JavaEE”当成一种技术范畴的表述，而不是硬性规定。在答辩口径里，你可以说“本系统基于JavaEE体系下的主流Web技术栈实现”。实际开发时，大部分同学用的是下面三种组合之一：
| 技术组合 | 特点 | 适合人群 |
|---|---|---|
| JSP + Servlet + JDBC | 最传统，纯手工，代码冗余 | 课程设计 |
| SSM(Spring + SpringMVC + MyBatis) | 经典JavaEE轻量级框架，分层清晰 | 大多数毕设 |
| Spring Boot + MyBatis/MyBatis-Plus | 配置简化，开发效率高，流行 | 有一定基础同学 |
我最后选的是SSM框架。理由很简单：导师看到“SSM”就知道是JavaEE方向的传统三件套，不会怪你脱离题目；而且网上关于SSM的资料满天飞，遇到问题随便一搜就能解决。如果你是想省事并且能自圆其说，用Spring Boot也完全没问题，只要在论文里把它包装成“在JavaEE技术体系下采用Spring Boot框架进行快速开发”就行。
1.2 交通违章处理系统的业务范围界定
这个题目的核心不是“车辆管理”，也不是“驾驶员管理”，而是“违章处理”。很多同学把三者同等对待，结果系统面目模糊。你要先想清楚一个违章从发生到完成处理的完整链路：
- 交警或者电子监控发现违章行为，记录违章时间、地点、类型、车辆信息。
- 系统生成一条待处理违章记录，同时关联到对应车辆和车主(驾驶员)。
- 车主登录系统查询违章，确认违章细节。
- 车主可以选择在线处理，走模拟缴款流程（毕设里不需要接支付接口，做个状态标记即可）。
- 罚款缴纳后，违章记录状态改为“已处理”，标志消除。
这个流程理清后，功能边界就出来了：车辆信息管理、驾驶员/车主管理、违章记录管理、违章查询统计、违章处理、系统用户管理。你看，这些功能都是围绕“违章”这根线串起来的，而不是孤立的增删改查。
1.3 技术栈对比：JSP/Servlet、SSM、SpringBoot怎么选
具体对比一下，方便你在开题阶段就做好选型，避免开发到一半发现方向不对。
JSP + Servlet：属于JavaWeb最原始的形态。你需要手写大量doGet、doPost，转发跳转靠RequestDispatcher，页面里嵌Java代码。优点是不依赖复杂框架，原理清晰，适合基础薄弱甚至没接触过框架的人；缺点是真的折磨人，一个简单的分页查询要写五六个文件，而且代码风格可能被答辩老师嫌弃“过于老旧”。
SSM：Spring管理对象，SpringMVC处理请求映射，MyBatis负责数据库操作。三层解耦后，业务逻辑写在Service层，控制层只做参数接收和视图跳转。这套组合有一个好处：它的分层方式在论文结构里特别好写，几乎是一一对应的。你写“控制层-业务层-持久层”的设计说明时，代码里也是这么分的，答辩也容易讲清楚。
Spring Boot：把SSM中的大量XML配置省掉了，内置Tomcat，一键启动。如果你的项目要求“能跑起来就行”，选它确实最有效率。但有个隐患：很多答辩老师会盯着问“你这不符合JavaEE标准规范吧”。这时候你需要会说一句“Spring Boot本质上是JavaEE规范的现代实现方式，简化了部署和配置，底层还是Servlet机制”。提前准备这句话，基本就能糊弄过去。
我自己的经验是：能稳妥就选SSM，能折腾就选Spring Boot。如果你的目标是顺利毕业而不是研究框架原理，选前者更稳妥。
2. 从需求到模块：系统功能拆分与角色设计
2.1 三类角色与权限边界
交通违章系统不像电商系统那样角色复杂，但“谁登录、谁能干什么”这件事必须划清。我设计的是三类角色：
- 系统管理员（Admin）：最高权限。管理所有基础数据，包括车辆信息、驾驶员信息、违章记录、系统用户，还能查看统计报表。
- 交通执法人员（Officer）：也就是录入违章的工作人员。负责新增违章记录、修改违章信息、对已处理记录进行核销。这类角色不需要管理用户和车辆，权限被收窄到违章业务本身。
- 车主/驾驶员（User）：普通的查询用户。登录后可查看本人名下的车辆违章情况，点击按钮进行违章处理（模拟缴纳罚款），处理完成后看到违章状态变为“已处理”。
权限边界想清楚以后，在代码里实现起来也不复杂。最直接的方式是加一个拦截器，根据session中用户的role字段判断允许访问的URL。不需要引入Shiro或Spring Security这种重量级框架，毕设项目用拦截器足够，也方便你在论文里写清楚“基于拦截器的访问控制机制”。
2.2 违章处理的完整业务流：录入-审核-处罚-缴款-销案
一定要把这个流程画出来（别用mermaid，直接在word里截图），因为这是答辩老师最爱问的。我建议的流程是：
- 执法人员登录系统，进入违章录入页面。
- 选择车辆（通过车牌号模糊搜索，自动带出车主信息）。
- 填写违章时间、违章地点、违章类型、罚款金额、扣分分值、违章照片（可选）。
- 提交后违章记录的状态为“未处理”。
- 车主登录查询到该记录，确认无误后点击“在线处理”，系统模拟生成处理流水号，状态变为“已缴款/已处理”。
- 执法人员可以在后台查看处理结果，也可按时间段、按类型做统计分析。
注意，扣分这件事在毕设里不需要做得太复杂，比如扣满12分自动吊销驾照之类的逻辑可以不做。只要在字段里记录扣了多少分就行。因为一旦引入复杂的驾照状态流转，你的代码量会翻几倍，而且容易出错。
2.3 功能模块清单与优先级排序
我把完整的模块列一下，开发的时候按优先级来：
- 基础模块：用户登录、注销、修改密码。
- 车辆管理：车辆信息的增删改查，车牌号唯一，关联车主。
- 驾驶员管理：驾驶员信息，关联其名下车辆。
- 违章管理：违章记录的录入、查验、修改、删除（删除权限一般只给管理员）。
- 违章查询：按车牌号、违章时间、处理状态多条件组合查询。
- 违章处理：车主确认违章并模拟缴纳，更新状态。
- 统计模块：按月份统计违章数量，按违章类型占比展示柱状图/饼图。
- 个人中心：车主查看个人车辆和违章情况。
其中车辆管理、违章管理、违章查询处理是核心，统计是加分项。很多同学在统计上卡壳，其实用ECharts前后端组合就能实现，后端返回JSON数据，前端直接渲染图表，这个我会在后面详细讲。
3. 数据库设计：违章业务的核心表结构
3.1 实体关系梳理与ER设计思路
数据库设计是这个题目的灵魂。如果表结构有问题，后面写代码会越来越别扭。我梳理出的核心实体包括：用户、车辆、驾驶员、违章记录、处理记录。
实体之间的关系大概是：
- 一个用户可以是驾驶员，一个驾驶员可以拥有多辆车。
- 一辆车可以有多条违章记录。
- 一条违章记录对应一次处理，处理结果记录在违章表自身或单独的处理流水表中。
为了省事，很多人的做法是：用户表里直接放车主信息，包括身份证号、驾驶证号、电话、车牌号。这样一表搞定，写查询的时候超级简单。但这属于教学系统里能跑、毕设里被怼的设计——因为车辆和驾驶员是独立实体，车牌号不止绑定一个人，比如公司车辆。我建议还是要拆开：
t_user（系统登录账号，分为admin/officer/user三种角色）t_driver（驾驶员信息，外键关联user可选）t_vehicle（车辆信息，外键关联driver）t_violation（违章记录，外键关联vehicle）t_process（可选，违章处理流水）
这样设计，表与表之间的关联清晰，论文里画ER图也方便，更重要的是答辩老师看到你的表之间不是“一张大表走天下”，会认为你确实理解了关系型数据库。
3.2 核心表字段设计（车辆表、驾驶员表、违章记录表、处理记录表）
直接给一份我在项目中设计过的表结构，供你参考。这里用MySQL语法演示。
驾驶员表 t_driver
CREATE TABLE t_driver ( id INT PRIMARY KEY AUTO_INCREMENT, driver_name VARCHAR(50) NOT NULL COMMENT '姓名', license_no VARCHAR(30) NOT NULL UNIQUE COMMENT '驾驶证号', phone VARCHAR(20) COMMENT '联系电话', id_card VARCHAR(30) COMMENT '身份证号', address VARCHAR(200) COMMENT '住址', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );车辆表 t_vehicle
CREATE TABLE t_vehicle ( id INT PRIMARY KEY AUTO_INCREMENT, plate_no VARCHAR(20) NOT NULL UNIQUE COMMENT '车牌号', vehicle_type VARCHAR(20) COMMENT '车辆类型：小型汽车/大型货车等', brand VARCHAR(50) COMMENT '品牌型号', driver_id INT COMMENT '车主驾驶员ID', register_date DATE COMMENT '注册日期', status TINYINT DEFAULT 1 COMMENT '1正常 0注销', constraint fk_vehicle_driver foreign key (driver_id) references t_driver(id) );违章记录表 t_violation
这是最核心的一张表。重点字段包括：
CREATE TABLE t_violation ( id INT PRIMARY KEY AUTO_INCREMENT, vehicle_id INT NOT NULL COMMENT '车辆ID', violation_type VARCHAR(50) COMMENT '违章类型，如超速/违停/闯红灯', violation_time DATETIME COMMENT '违章发生时间', location VARCHAR(200) COMMENT '违章地点', penalty_amount DECIMAL(10,2) COMMENT '罚款金额', deduct_points INT COMMENT '扣分分值', status TINYINT DEFAULT 0 COMMENT '0未处理 1已处理', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, process_time DATETIME COMMENT '处理时间', process_desc VARCHAR(200) COMMENT '处理备注', constraint fk_violation_vehicle foreign key (vehicle_id) references t_vehicle(id) );penalty_amount一定要用DECIMAL，不要用float，不然金额会出现精度怪问题，答辩演示的时候突然多出0.01就很尴尬。status字段用tinyint的0和1去表示，非常直观。如果你还想要更细的状态，比如“已审核”“已生成处罚决定书”，可以扩成整数枚举，但毕设没必要。
系统用户表 t_user
CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL COMMENT '存储MD5或BCrypt后的密文', real_name VARCHAR(50), role VARCHAR(20) DEFAULT 'user' COMMENT 'admin/officer/user', driver_id INT COMMENT '关联驾驶员，仅角色为user时使用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );这里有一个重要的思路：t_user和t_driver是允许分离的。车主用户既可以先有账号再绑定驾驶员信息，也可以在创建驾驶员时自动创建一个登录账号。要保证用户名唯一并且密码不能明文存储，哪怕是毕业设计，明文密码也会被答辩老师一眼看穿。
3.3 状态字段与统计查询的SQL设计技巧
状态字段的意义在于，让所有业务模块都能围绕“状态”做文章。比如：
- 未处理的违章列表：
select * from t_violation where status = 0 - 某个车牌号的所有未处理违章：
select v.* from t_violation v join t_vehicle ve on v.vehicle_id=ve.id where ve.plate_no=? and v.status=0
你已经做统计时，最常用的是分组聚合：
-- 按月份统计违章数量 SELECT DATE_FORMAT(violation_time, '%Y-%m') as month, COUNT(*) as cnt FROM t_violation GROUP BY DATE_FORMAT(violation_time, '%Y-%m'); -- 按违章类型统计占比 SELECT violation_type, COUNT(*) as cnt FROM t_violation GROUP BY violation_type;这个SQL写出来，后端把它查出来转成JSON，前端用ECharts画图就非常顺手。需要注意日期格式化时%Y是大写，代表四位年份；%y是小写，代表两位年份。很多同学在日期格式上栽过跟头，返回的结果跟预期不一样就对不上。
另外在设计时可以考虑冗余字段：比如在t_violation里直接存车主的手机号或车牌号字符串，虽然违反了严格的三范式，但查询时会少很多关联，图片展示也更方便。毕设不是大型高并发系统，适度冗余是被允许的，你可以在论文里写“考虑到查询效率，本设计采用了适度冗余”。
4. 前后端代码实现的关键环节
4.1 分层架构与包结构规划
我采用的是经典三层架构加JSP页面表现层，如果你用Spring Boot也一样。包结构可以这样规划：
com.example.traffic ├── controller // 控制层：接收请求，返回ModelAndView或JSON ├── service // 业务层：接口+实现，处理业务逻辑 ├── dao // 持久层：MyBatis的Mapper接口 ├── entity // 实体类：对应数据库表 ├── interceptor // 登录拦截器、权限拦截器 ├── utils // 工具类：公共方法 └── vo // 视图对象：用于向前端返回组合数据很多同学的代码坏就坏在Controller里堆了一堆SQL逻辑，Service层形同虚设。你要记住：Controller只负责接收参数和返回结果，具体业务逻辑必须放到Service层。比如处理违章这个动作，Controller里只需要调用violationService.process(Integer id)，至于先查状态、再更新状态、生成流水号，都在Service里完成。这样写论文时，你直接可以逐个Service方法来讲业务设计。
4.2 登录认证与会话管理
登录是所有管理系统的入口。我建议使用基于Session的会话管理，简单直接，适合毕设。
核心流程：
- 用户在登录页面输入用户名密码。
- 后端根据用户名查出记录，比对密码（对密码先做MD5加密或者BCrypt校验）。
- 验证通过后，把用户实体和角色信息放入session。
- 拦截器检查每个请求，如果session为空，就重定向到登录页。
- 根据角色判断是否允许访问某些路径，比如
/admin/**只能由admin访问。
拦截器的判断逻辑写一个简单的例示：
public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return false; } return true; } }如果要区分角色，就在拦截器里加URI和角色的匹配。这样做的好处是逻辑单一，不想引入权限框架的话足够了。
4.3 违章记录的增删改查与分页查询
这个部分看着简单，但细节很多。以“分页查询”为例：
前端JSP页面通过表单提交查询条件，后端接收pageNum、pageSize、plateNo、status等参数，调用Service层拼接查询条件。用MyBatis的PageHelper或者自己手写limit都行。我建议用PageHelper，因为它是插件式调用，不污染SQL。
一个常见错误是明明传了plateNo却查不到数据，原因往往是表单里字段名和实体属性名不一致。比如前端传的是vehiclePlateNo，后端实体字段却是plateNo，就会一直为空。解决办法是统一命名，或者在接收参数时用@RequestParam指定。
违章记录列表页通常要显示车牌号、车主姓名、违章类型、违章时间、状态等组合信息。这个在DAO里要做一个联合查询，而不是只查t_violation表，然后一条条去取车辆信息。提前定义好一个VO类：
public class ViolationVO { private Integer id; private String plateNo; private String vehicleType; private String driverName; private String violationType; private Date violationTime; private String location; private Double penaltyAmount; private Integer deductPoints; private Integer status; // getter/setter... }XML映射文件里写一条多表关联SQL：
<select id="queryViolationList" resultType="com.example.traffic.vo.ViolationVO"> select v.id, ve.plate_no as plateNo, ve.vehicle_type as vehicleType, d.driver_name as driverName, v.violation_type as violationType, v.violation_time as violationTime, v.location, v.penalty_amount as penaltyAmount, v.deduct_points as deductPoints, v.status from t_violation v left join t_vehicle ve on v.vehicle_id = ve.id left join t_driver d on ve.driver_id = d.id <where> <if test="plateNo != null and plateNo != ''"> and ve.plate_no like concat('%', #{plateNo}, '%') </if> <if test="status != null"> and v.status = #{status} </if> </where> order by v.create_time desc </select>这里用了left join，可以保证即便车牌或驾驶员信息缺失，违章记录本身还能查出来。like用concat拼接，能防止SQL注入，也兼容不同数据库。这些细节点在论文里都能写成“数据库安全设计”的素材。
4.4 报表统计与图表展示的简易实现
统计模块是让系统看起来“高级”的关键。不用做太复杂，两个图表就够：
- 按月份统计违章趋势：折线图。
- 按违章类型统计占比：饼图。
后端写一个接口：
@Controller public class StatController { @Autowired private ViolationService violationService; @RequestMapping("/admin/statistics") @ResponseBody public List<Map<String, Object>> getStatistic(String type) { if ("month".equals(type)) { return violationService.statByMonth(); } return violationService.statByType(); } }前端页面引入ECharts的CDN，使用Ajax请求接口数据，然后设置option渲染即可。需要注意后端返回的字段要与ECharts的数据格式匹配，比如饼图的data需要[{name: '超速', value: 12}]，那你SQL查询出来的字段就命名为name和value，或者在Java里组装成这个结构。
我曾经见过同学直接返回两个List，一个存类型名，一个存数量，然后前端强行拼数据，最后图表死活不显示。其实只要你理清ECharts的data数组结构，前端代码就几行的事。
5. 说明文档与LW（论文）的写作框架
5.1 文档应该包含哪些章节
毕设打包通常有说明文档和LW（也就是论文），两者的侧重点不一样。说明文档更偏向使用说明和部署步骤，论文则要体现设计思路。一个合格的说明文档至少要有：
- 系统环境要求：JDK版本、Tomcat版本、MySQL版本、Maven或IDE。
- 数据库初始化步骤：导入SQL文件、修改连接配置。
- 启动部署步骤：无论是Eclipse/IDEA里运行，还是打包成war放到Tomcat，必须一步一步写清楚。
- 系统操作手册：管理员、执法人员、车主三种角色分别怎么操作。
- 常见问题：比如端口冲突怎么办、数据库连不上怎么办。
论文的框架就典型得多，一般是：
- 绪论（背景、意义、国内外现状、主要工作）
- 需求分析（可行性分析、功能需求、非功能需求、用例图）
- 系统设计（总体架构、功能模块设计、数据库设计、界面设计）
- 系统实现（按模块截图+代码核心片段+文字说明）
- 系统测试（测试用例、测试结果、结论）
- 总结与展望
如果你项目已经做完再写论文，其实很快。每个模块先截图，再写“前端页面通过XX方式请求后端接口，后端接到请求后执行XX逻辑，最终返回结果。”模板化不可怕，只要代码对应得上，老师不会太刁难。
5.2 论文篇幅与图表要求
一般本科毕设论文要求8000到15000字，有的学校要求1万字以上。交通违章系统的图表比较多，至少要有：
- 系统架构图
- 功能结构图
- 业务流程图
- ER图
- 主要表结构说明表
- 运行截图若干
- 测试用例表
这些图表不是随便截屏就行，要保证清晰、标注规范。我的习惯是先用Visio或者draw.io画草图，再放到论文里统一字体。架构图不要追求花哨，用简单的矩形+箭头就能表达清楚。
5.3 答辩演示的常见提问点
答辩最容易被问的，我把高频问题列一下，提前准备好足够：
- 为什么选用这个框架？
- 系统里有哪几个核心实体？它们之间是什么关系？
- 违章处理的业务状态是怎么流转的？
- 不同角色的权限是如何控制的？
- 如果某条违章录入错误，怎么修改或删除？
- 你的统计图表是怎么实现的？数据从哪里来？
- 数据库连接信息怎么配置？如果部署到别的机器上要注意什么？
这些问题只要你代码是自己写的，基本都能答上来。但很多同学用现成包，连项目的包结构都说不清，这就很危险。所以哪怕是使用现成代码，也要把项目完整跑一遍，核心类打开看一遍，知道每个方法是干嘛的。不需要全会，但关键入口要能说两句。
6. 调试与定制过程中的避坑指南
6.1 环境配置最常见的坑
这个题目最容易栽的环境问题有：
JDK版本不匹配：用Spring Boot 2.x时，JDK8就行；如果用较新的Spring Boot 3.x，JDK17以上才可以。而有些同学的Tomcat还是8.5，如果用的是Servlet规范太新的版本，会提示
UnsupportedClassVersionError。解决方法是把JDK版本和Tomcat版本对照好，别拿9的编译包丢到8的容器里。Tomcat部署路径问题：打成war包后默认访问路径通常是
http://localhost:8080/projectName/，如果你在代码里写了绝对路径/login.jsp，部署后找不到资源。所以前后端跳转尽量用相对路径或带contextPath的路径。JSP页面推荐在开头加<% String path = request.getContextPath(); %>，再用<%=path%>拼接路径。MySQL时区问题：连接串里必须加上
serverTimezone=Asia/Shanghai，否则跑起来你会发现时间变成了英国时间，差八个小时。这个问题极其常见，几乎每个用高版本MySQL的同学都会遇到一次。数据库主键策略：用
AUTO_INCREMENT很省心，但如果你用了MyBatis的useGeneratedKeys做插入，必须保证实体类的字段和主键对应，否则插入后拿不到自增ID，联调时就麻烦。
6.2 部署上线时的数据库与路径问题
如果你最终要演示给别人看，建议把数据库脚本完善到“一键导入”的程度。不要只给一个.sql文件，里面还得带测试数据。测试数据非常重要，比如你演示列表页时，如果没有数据，界面空空如也，观感极差。插入测试数据时注意关联ID要保持正确，避免车辆存在了但驾驶员ID对不上。
如果是从别人那里拿来的项目，一定要检查数据库连接配置，尤其是jdbc.properties中的IP是不是写成了localhost。一旦你要部署到云服务器或者别的机器，就必须改掉。密码不要泄露，但可以自己改成你本地的。
文件上传也经常出问题，比如违章照片上传后，到了演示现场发现图片不显示。根本原因在于上传路径写的是本机绝对路径，换了环境就失效。稳妥的做法是：把图片存储路径配置到项目外部，并写一个虚拟映射把图片所在目录映射出来，或者干脆把图片以Base64方式存库（毕设数据量小，完全可行）。这样部署到哪里都能看到图。
6.3 定制需求如何改动最小化
很多时候你从网上下载的代码并不完全符合你自己开题报告里的功能描述，比如你的课题里写了“支持批量导入车辆信息”，但是源码没有。这时候不要急着大改，先在表结构满足的前提下加一个上传功能，用Apache POI导入Excel。改起来也就几十行代码，但整篇论文就可以多写一个小节。
另一种定制是角色调整。比如你的题目叫“车辆违章信息管理系统”，但老师要求把黑名单车辆也管起来，你只需要在t_vehicle表里加一个blacklist字段，然后在查询页面加一个筛选条件即可。凡是这种小需求，尽量用加字段、加查询条件的方式完成，不要动表结构核心关系，否则容易引起连锁bug。
我个人最佩服的一种做法是：先跑通原项目，确定能启动，然后每天只改一个小需求并测试，稳扎稳打。切忌一开始就重构代码，重构到一半发现原项目已经跑不起来了，最后只能哭着去找售后。
7. 这套系统做完，你能带走什么
很多人觉得交通违章系统太老，没技术含量。但这个题目其实很适合作为JavaWeb的完整训练项目，因为它的业务链完整，涉及权限、多表查询、状态流转、统计报表，还有很多边界情况可以扩展。做完这个系统，你对SSM或者SpringBoot的掌握会从“会写demo”到“能做一个完整应用”，尤其是数据库设计和业务逻辑分离的思路，下次换个野题目也能迁移过去。
而且这个系统的可扩展性并不差：你可以给用户增加积分、给违章加上图片识别、用车牌识别API、接支付模拟、加消息通知。答辩时如果老师问“未来还能怎么改进”，这些都是现成的答案。
最后再分享一个我自己的实际操作经验：在整理提交物的时候，一定要把代码和文档的目录结构对齐，然后写一个README.md放在项目根目录，里面写清楚环境要求、启动步骤、默认账号密码。这一小步看着不起眼，但等过一个月你自己回头看代码时，就会感激当初的这几十行说明。好的毕设不是一蹴而就，而是那些细节一点点堆出来的。
