基于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。字段包括车位编号、车位区域、车位类型（普通/新能源/无障碍）、当前状态（空闲/占用）。入场时要把车位状态从空闲改成占用，出场时再释放回空闲，这是一对非常自然的状态流转。

第三类也是最核心的业务表：entry_record。它是整个停车场的“流水账本”。

字段如下：

这张表设计的关键在于：入场时生成一条记录，出场时更新同一条记录。状态字段和出场时间共同承担“防重复结算”的职责。

第四类是计费规则表 fee_rule，第五类是支付流水表 pay_record。规则表把收费标准和车辆类型关联起来，支付流水表记录每一笔费用的支付时间、支付方式、操作人。固定车如果做了续费功能，也可以单独建一张 renewal_record 表，或者并入财务流水，看你的论文模块怎么划分。

2.2 金额为什么用“分”来存

这是个很小、但能看出一个人的项目是否真正“上过生产”的细节。如果金额用double类型，计算0.1+0.2会得到0.30000000000000004，这在支付场景里是不能接受的。停车场收费精确到分，所以我在项目里统一用Integer或Long类型存“分”，而不是用BigDecimal去存“元”。

前端显示的时候再转成元格式。这样处理其实并不复杂：

java复制public String formatAmount(Integer amountInFen) {
    if (amountInFen == null) {
        return "0.00";
    }
    return String.format("%d.%02d", amountInFen / 100, amountInFen % 100);
}

有的人会觉得用BigDecimal就行，也没毛病，但既然存的是整数，代码里根本不会出现浮点运算，精度问题在源头被规避了。这件事在答辩时也很加分——可以顺势讲出“为什么不用double”的经典问题。

2.3 三个容易被忽略但很重要的字段决策

第一个是逻辑删除。很多毕设项目里，车位删了就是真删了，管理人员不小心点错按钮，数据全没了，影响很坏。我建议所有基础表都加 deleted 字段或 status 来标记停用和删除，而不是物理删除。尤其是车位和车辆数据，删除后会影响历史进出记录的完整性和报表统计。

第二个是“计费规则快照”。刚做这个项目的人容易犯一个错误：出场时去查最新的收费规则。这会导致一个严重问题——如果管理员在车辆入场后修改了费率，出场时系统按新费率收费，车主肯定会投诉。正确做法是入场时把车辆适用的规则id写入 entry_record，出场结算时优先取快照中的规则。如果这条记录没有规则快照（比如老数据），再退回去查规则表。这个细节很多网上的代码压根没考虑。

第三是 create_time 和 update_time 的统一管理。在MyBatis-Plus里用 @TableField(fill = FieldFill.INSERT) 和自动填充的MetaObjectHandler就能搞定，不需要每个插入语句手动写当前时间。

3. 计费模块，整个软件最值得讲的业务核心

3.1 真实停车场的收费规则，往往不是按时收费那么简单

很多人觉得计费就是“一小时五块”，然后出场时乘以停放小时数。但你稍微想想真实的停车场：有的车停不到半小时不收钱，有的过夜要单独加钱，有的每天有封顶价，有的白天和夜间费率不一样。如果只做最简单的按时计费，功能上确实能跑通，但答辩时显然缺少亮点。

我的方案是，把规则抽象成一张配置表，而不是把逻辑写死在代码里。配置表的字段大概是这样：

• 规则名称：比如“临时车标准”
• 适用车型：临时车/月租车/新能源车
• 免费分钟数：入场后多少分钟内免费
• 首小时费用：停车的第一个小时收费多少
• 续时费用：从第二小时开始，每小时收费多少
• 每日封顶金额：同一自然日内最高收费
• 是否启用：启用后新入场车辆才使用该规则

这样一来，管理员可以在后台直接改费率，而不需要改代码重启服务。这个设计体现了“配置与代码分离”的思想，论文里也能写成一个小亮点。

3.2 把计费步骤拆成可测试的小块

我最开始写计费时，试图在一个方法里完成所有判断，结果代码越长越难调。后来我把计费拆成三个方法，每一种都写单独的单元测试，效果好了很多。

第一步是判断车辆类型，决定走月租车免费通道还是临时车收费通道。月租车如果过期了，不能直接拒绝出场，而应该按临时车规则补缴停车费，这也是一个容易忽略但很实际的场景。

第二步是把入场到出场的时间段，按“自然日”切分。为什么要这样切？因为“每日封顶”通常是按自然日计算的。一辆车从晚上十点停到第二天早上八点，跨了两天，如果直接算总时长再封顶，逻辑上对不上。

第三步是在每一个自然日区间内，应用规则计算费用：

java复制public long calcOneDayFee(LocalDateTime enterTime, LocalDateTime exitTime, FeeRule rule) {
    long minutes = Duration.between(enterTime, exitTime).toMinutes();
    // 不足一分钟按一分钟算，这里根据业务要求决定
    if (minutes <= rule.getFreeMinutes()) {
        return 0;
    }
    // 按小时向上取整
    long hours = (minutes + 59) / 60;
    long fee = rule.getFirstHourFee();
    if (hours > 1) {
        fee += (hours - 1) * rule.getContinueHourFee();
    }
    long cap = rule.getDailyCap();
    return Math.min(fee, cap);
}

上面只是一个核心逻辑片段的示意，真正落地时还要处理“不满一分钟怎么算”“跨天后的首小时是否重新计算”等边界情况。我建议把这些边界点写成一连串的单元测试用例，不光能自测，答辩演示时也很有说服力。

3.3 重复出场和并发点击怎么防

这是很多毕设项目里真正的“坑”。如果用户在出场页面手滑点了两次“结算”，代码逻辑不严谨的话，同一笔停车费会被收两遍。尤其是现在很多毕设的前端都加了异步请求，重复提交非常容易出现。

我用的方案是“状态字段+更新条件”。出场结算时，不是先查记录再更新，而是直接用一条带条件的update语句实现原子操作：

java复制int rows = entryRecordMapper.update(null, new LambdaUpdateWrapper<EntryRecord>()
    .eq(EntryRecord::getId, recordId)
    .eq(EntryRecord::getStatus, 0)   // 只允许在场记录被结算
    .eq(EntryRecord::getExitTime, null)
    .set(EntryRecord::getStatus, 1)
    .set(EntryRecord::getExitTime, LocalDateTime.now())
    .set(EntryRecord::getPayAmount, fee));

当更新影响行数为0时，说明这条记录已经被别人结算过了，程序就直接返回“该车辆已出场，请勿重复操作”。这种写法把业务判断交给数据库，大大减少了并发问题，代码也比“先查询再判断再更新”简洁得多。

3.4 Spring事务别“大包大揽”

入场和出场的操作往往涉及多张表的更新，比如出场时要更新停车记录状态、生成支付流水、释放车位，还需要用 @Transactional 保证原子性。这里要提醒自己：事务的范围不是越大越好，尤其是不要在事务里调用远程接口或长时间阻塞等待。如果做支付对接，绝对不能把“调第三方支付接口”放在一个大事务中间慢慢等，否则数据库连接会被长时间占用。

在这个项目里，我的设计是：先做本地记录更新并提交事务，再处理支付结果回调。如果支付失败，就允许用户重新发起结算，依然以状态字段判断是否能再次结算，这样系统既不会重复扣费，也不会因为一次支付超时导致整个事务回滚。

4. Spring Boot 项目里那些不会写进教程的配置细节

4.1 JDK版本和Spring Boot版本，是一道送命题

打开网上的毕设教程，有的用JDK8+Spring Boot 2.x，有的用JDK17+Spring Boot 3.x。如果你只是照着代码敲，版本错了会浪费一晚上。

关键区别是：Spring Boot 3.0开始，JavaEE的包名从 javax.* 换成了 jakarta.*，部分第三方依赖也要换新版本。很多网上的老代码在Spring Boot 3下直接编译不过。我个人的建议很明确：除非你想体现自己对新技术的学习能力，否则毕设项目不要追新，选 Spring Boot 2.7.x + JDK8 是最稳妥的组合，教程最多、问题最少、能查到的解决方案也最多。

如果你所在学校要求必须用较新的Spring Boot 3，那就要接受“很多老资料失效”的现实，优先看官方文档。别一边用Spring Boot 3一边拿着Spring Boot 2的代码改，会非常痛苦。

4.2 LocalDateTime引发的“三次心态爆炸”

我在项目里全程使用 LocalDateTime 来表示时间，因为它是Java 8推荐的日期时间API，比老的 java.util.Date 好用太多。但新手上路时会遇到几个典型问题：

第一个问题是后端返回JSON时，LocalDateTime 默认序列化格式不是 yyyy-MM-dd HH:mm:ss，而是一长串带 T 的格式。解决办法是在 application.yml 里做全局配置，或者用 @JsonFormat 注解在字段上标注格式。

第二个问题是前端传时间参数时，如果没有用统一格式，后端解析会直接报错。我建议前端统一传字符串，后端用 @DateTimeFormat 或配合Jackson的全局配置去解析。

第三个问题是数据库时区。如果MySQL连接串上不写 serverTimezone=Asia/Shanghai，高版本驱动可能默认读取系统时区，结果你写入的时间和查出来的时间差几个小时。这是非常隐蔽的坑，数据看着不对，还很难排查。

4.3 小规模系统，不要一上来就拆微服务

某天我在一个毕设交流群里看到有人问“停车场收费系统要不要拆成微服务”，下面还有人认真回答。这就属于完全没搞清楚项目定位。毕设项目的核心是展示你对业务的建模能力、对Spring Boot常用组件和数据库设计的掌握程度，不是把系统拆成注册中心、网关、多个服务。单体应用在这个业务规模下依然是合理的选择，维护简单、部署简单、逻辑清晰，答辩老师也更容易看懂。

4.4 前后端交互要留好接口文档

如果是纯后端项目，用Thymeleaf模板渲染页面，问题不大。如果是前后端分离项目，建议用Swagger/knife4j自动生成接口文档。写完接口后先通过Swagger页面自测一遍，比用Postman一个个维护请求头省力很多。接口文档还有一个隐藏价值：论文里的“系统详细设计”章节可以直接引用接口列表，比自己手画一大堆难看又难调的表格更直观。

5. 自测、答辩和论文，让项目真正“完整交付”

5.1 拿这组用例先过一遍功能

代码写完之后，不要急着截图写论文。先按真实车场的运营场景做一遍自测，我把自己总结的测试用例分享在这里。

• 临时车正常入场、正常出场，按小时计费是否正确。
• 入场后不足免费时长，出场是否应收0元。
• 停车跨天且设置了每日封顶，费用是否按天拆分计算。
• 月租车在有效期内出入场，不产生应收金额。
• 月租车过期后出场，系统是否按临时车规则计费。
• 出场结算按钮连续点击两次或两个窗口同时点，是否只生成一笔支付流水。
• 车位已满时再尝试入场，是否给出明确提示。
• 后台修改计费规则后，已在场的车辆出场时是否仍然按入场时的规则结算。

这张清单里的每一个项目，都应该有可以复现的操作步骤和预期结果。这些记录写进论文的“系统测试”章节，远比那种“系统运行正常，符合需求”的空话有价值。我当时把测试表格整理了整整三页，答辩老师看到都点头。

5.2 答辩演示动线：从月租车开始，到报表结束

答辩演示很忌讳东点一下西点一下，评审老师看了几分钟也不知道你的系统好在哪里。我建议按一条演示主线走：

管理员登录后台 → 展示车辆管理、车位管理、规则设置 → 新增一辆月租车 → 月租车入场，车位从空闲变成占用 → 月租车出场，页面显示不收费并释放车位 → 新增一辆临时车入场 → 模拟停车超过免费时长后出场 → 展示应收金额、结算成功、支付流水生成 → 再到统计页面展示今天的总收入与停车时长分布。

这条动线展示了完整的业务闭环：基础数据维护、入场、出场、计费、支付、统计。每一步之间逻辑衔接紧密，老师不容易走神，你也不容易讲乱。

5.3 写论文时，重点讲清楚“为什么这么做”

论文最容易写成“操作说明书”——先点这个按钮，再点那个按钮。这种文字对评审老师没有说服力。核心章节应该写清楚你做了什么设计决策，以及基于什么理由。比如：为什么金额用分存储？为什么用状态字段防重复结算？为什么计费规则不写死在代码里？这些决策背后都有明确的工程原因，写出来才能体现你真正做了设计。

我在实际写作中，把“计费模块的设计与实现”作为论文的核心章节，用一张流程图配三个时序场景把这部分讲透。这里提醒一句：画图时不要用那种无法在Word里正常显示的在线图，正常插入Visio或ProcessOn导出的图片就行。

最后再分享一个真实教训

这个项目做到后期，我觉得最耽误时间的不是写代码，而是“觉得代码写得差不多了，先歇一天”。隔了一周再回头看，很多逻辑已经忘了，连调试都变得断断续续。后来我给自己定下一个规矩：每天用半小时把当天写的接口在Swagger或前端页面上完整跑一遍，看到数据落库了再收工。就是这样一个笨办法，让我在正式答辩前几乎没有遇到过“系统演示到一半页面报错”的尴尬状况。

如果你现在正准备做这个课题，建议把“跑通一个完整流程”当成每天的里程碑，而不是把“代码写完了”当成里程碑。毕竟毕设最后看的是能运行、能讲解、能回答问题的完整系统，不是藏在磁盘里的半成品源码。