基于Spring Boot的停车场收费管理系统：从源码到答辩的完整实践

如果你最近正在搜“基于springboot的停车场收费管理系统源码”，多半是毕业设计的选题阶段到了。我当初也一样，网页上清一色的“源码+文档+可运行”，看着很省事，结果真正把压缩包下载下来，反而被那些“导入即跑”的说明坑了整整两天——数据库脚本报错、JDK版本对不上、页面点几下就白屏。最后我索性丢掉别人那份代码，自己从表结构开始重新做了一遍。做完之后我才发现，这个项目真正的难点根本不在CRUD，而在停车计费规则怎么设计、订单状态怎么防重复结算、答辩的时候怎么把系统的业务深度讲清楚。这篇文章就把我从选题到答辩的经验完整写一遍。

1. 题面很简略，但它真正要求的是一个完整的业务闭环

1.1 先拆解题面隐藏的三个角色

多数人看到“停车场收费管理系统”这几个字，第一反应就是“车辆进出记录+收费”，然后就急着去搜代码。但你仔细想想，一个能真正用的车场系统，至少要服务三类角色：

• 管理员：维护车场信息、车位信息、计费规则、查看统计报表。
• 操作员或前台收费员：负责车辆入场登记、出场结算、处理异常车辆。
• 车主（间接用户）：临时车扫码付款、月租车续费。

如果你用Spring Boot做后端，势必要考虑登录、权限、数据隔离。很多网上的代码把登录做成一个摆设，用不登录也能访问所有接口，这就很离谱了。毕设答辩时老师只要问一句“不同角色能做什么？你怎么控制的？”很多人就会卡住。

我建议最小实现可以不加Spring Security那么重的东西，但至少要有一个基于拦截器或AOP的登录校验，并且把管理员和操作员两个角色分开。角色不多，够用就行。

1.2 流程闭环没理清之前，不要急着建表

我见过不少同学做毕设是“先建二十张表，然后删到剩五张”。这背后的问题不是表多表少，而是业务闭环没想清楚。

停车场收费的核心流程其实是一条很清晰的主线：

车辆入场 → 记录入场时间 → 分配车位/标记在场 → 车辆出场 → 结算费用 → 生成支付记录 → 释放车位

围绕这条主线，所有功能模块都应该有明确归属。比如“车位管理”支撑的是“入场时判断有没有空位”；“计费规则”支撑的是“出场时算多少钱”；“收入统计”支撑的是“管理员看财务报表”。如果建表时没有这个概念，后面写代码就会越写越乱，经常出现一个字段不知道放哪张表、一个接口不知道调哪个Service的情况。

1.3 网上源码为什么经常跑不起来

我不否认网上有质量不错的开源项目，但毕设源码这个领域确实鱼龙混杂。常见的情况有：

• 数据库脚本由老版本MySQL导出，导入到MySQL 8报排序规则错误。
• Spring Boot版本太高或太低，和某些依赖不兼容。
• 项目里用了大量自己都没测过的第三方接口，比如车牌识别、支付回调。
• 删除了一些关键代码，留着看起来很全、实际跑不通。

所以我在这次项目中给自己定了一条规矩：核心业务代码必须自己写一遍，尤其是计费和结算部分。这样即便借用了别人的页面模板，心里也清楚每一行代码在做什么，答辩时才能讲得理直气壮。

2. 我最终落地的数据模型和选型理由

2.1 没做太花哨，但这几张表就够了

很多刚做毕设的同学喜欢一张表塞所有字段，觉得方便。真正写的时候才发现，业务一旦复杂，字段耦合会让人焦头烂额。我最后采用的数据模型没有追求大而全，而是紧扣业务闭环。

第一类是用户与车辆档案，对应 sys_user 和 vehicle_info。sys_user 存管理员和操作员账号，vehicle_info 存固定车、月租车的车牌号、车主姓名、联系方式、车辆类型、月租到期时间等。固定车之所以单独建表，是因为入场和出场时的处理逻辑与临时车完全不同——固定车不需要每次出场实时缴费，只需要校验月租状态是否在有效期内。

第二类是车位资源，对应 parking_space。字段包括车位编号、车位区域、车位类型（普通/新能