智能停车计费系统这个题目，看起来是典型的SpringBoot课设标配，但真正动手做过就会明白：系统的难点根本不在增删改查，而在计费规则的灵活性和出入场流程的边界处理。我前阵子刚好完整做了一套这样的系统，从入场记录、灵活计费引擎、订单支付回调到管理端统计报表都走了一遍，今天就把设计和实现过程中的关键决策、核心代码思路、还有踩过的几个坑完整梳理出来。如果你正准备拿这个题目做毕设，或者要给某个小停车场做一套能真正运营的改造，这篇文章应该能帮你少走不少弯路。
整套系统我采用的是SpringBoot单体架构，管理端走网页，单机部署，MySQL就能抗住日常停车场的吞吐量。系统最终覆盖的核心链路是：车牌入场时生成计费记录，出场时按规则实时计算费用，用户支付后订单自动归档，管理端每天可以查看收入、车流量和异常订单。下面我不按项目汇报的套路来讲，直接拆开每个模块说清楚"为什么这么设计"和"实际落地时要注意什么"。
1. 停车场计费没你想的那么简单：业务难点与系统边界
1.1 一个停车场每天都在发生什么
先别急着写代码，把业务场景梳理清楚是关键。一个典型的停车场日常会碰到这么几类车辆：临时车（进去就计时收费）、月租车（按月结算，出场直接抬杆）、内部车（免费放行）、无牌车（扫码入场，靠小票或手机号绑定）、特殊车辆（军警、救护、执行任务车辆）。出场的时候更复杂：临时车要算费、缴费后抬杆；月租车要判断是否过期、余额是否充足；还有车辆没入场记录却要出场的、入场记录没拍清车牌导致识别不到的、用户支付了但道闸没抬的。
这些场景说明一个问题：停车系统本质上是一个带状态流转的业务系统，不是一个简单的进出记录表。每一辆车从入场到出场，经历着"在场→待支付→已支付→离场→归档"的生命周期，而每一条状态的转移都可能被各种异常打断。设计阶段如果不把这些场景列全，后续接二连三的补丁会让代码越来越难维护。
1.2 计费规则才是最大的变数
很多初学者以为计费就是"小时乘以单价"，实际业务里规则五花八门。同一个停车场里，临时车可能是"首小时5元，后续每小时3元，24小时封顶30元"；商场联营的可能有"消费满100元免停2小时"；夜间包时段可能按"20:00到次日8:00一口价20元"；节假日还可能搞"全天封顶价下调"的活动。规则不是一成不变的，停车场运营方会按经营情况随时调整。
如果把这些规则硬编码在业务代码里，每次改价都要发版，那这个系统基本没办法长期运营。所以我在最初设计时就定了一个原则：计费参数全部数据化、配置化，运管员在管理后台改规则，系统按最新规则计算费用，代码只负责"计算逻辑"的通用实现。这个决策直接决定了后面计费引擎的架构形态。
1.3 哪些自己做、哪些对接成熟方案
做之前要先划清系统边界，防止在"自研"上钻牛角尖。车牌识别我不建议自己训练模型，直接对接摄像头厂商的SDK或HTTP接口，拿到识别结果就行；我做的是预留一个PlateRecognizer接口，让真正对接硬件时只需实现一个方法。道闸控制同理，通过一个简单的开闸/关闸HTTP接口或串口指令来联动，系统内部只需要定义好"开闸成功""开闸失败"的返回约定。支付环节需要自己接微信/支付宝的支付下单和回调，这是系统的一部分，不能省。剩下的人工兜底流程，比如无入场记录车辆的补录出场、识别失败时的手工开闸，也必须在系统里提供入口，不然停车场现场管理员会很难办。
边界清楚了，后面的开发才能聚焦到核心业务上，而不是被各种硬件SDK的琐碎细节拖垮。
2. 数据先行：表结构设计与订单状态机的搭建
2.1 为什么还是用SpringBoot单体架构
技术选型这块，我直接说结论：用SpringBoot + MyBatis-Plus + MySQL + Redis，管理端用Vue或Thymeleaf都可以，单体部署就够了。停车场业务的流量再怎么大，也就是一个中型小区的规模，每秒并发入场最多也就十几辆车，远远达不到需要微服务、消息队列的水平。单体架构最大的优点是开发快、调试方便、部署一个jar包就能跑起来，对毕设、课设、以及大多数小型停车场运营场景来说都是性价比最高的方案。
选SpringBoot还有一个现实原因：生态太成熟了。做权限可以用Sa-Token或Spring Security，做接口文档可以用Knife4j，做定时任务用Spring自带的@Scheduled就够，遇到问题网上一搜基本都有对应方案。对于需要一个能真正跑起来的项目来说，这套组合是最稳妥的。
2.2 核心表的结构设计思路
表结构设计是整个系统的地基，我建议从"一笔停车业务"的角度倒推需要哪些数据。核心就三张业务表：车辆出入场记录表、计费规则表、支付订单表，再辅以月租车表、用户表、操作日志表。
车辆记录表我命名为park_record，字段大致如下：
CREATE TABLE `park_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `plate_no` varchar(16) NOT NULL COMMENT '车牌号，统一去掉空格和特殊字符', `car_type` tinyint(4) NOT NULL DEFAULT 1 COMMENT '1临时车 2月租车 3内部车 4无牌车', `entry_time` datetime NOT NULL COMMENT '入场时间', `exit_time` datetime DEFAULT NULL COMMENT '出场时间', `status` tinyint(4) NOT NULL DEFAULT 0 COMMENT '0在场 1待支付 2已支付离场 3异常 4已退款', `rule_id` bigint(20) DEFAULT NULL COMMENT '使用的计费规则', `entry_channel` varchar(16) DEFAULT NULL COMMENT '入场通道', `operator_id` bigint(20) DEFAULT NULL COMMENT '操作员ID', `remark` varchar(255) DEFAULT NULL COMMENT '备注', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_plate_status` (`plate_no`, `status`), KEY `idx_entry_time` (`entry_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='车辆出入场记录表';注意plate_no的存储我做了规范化处理，统一去空格、统一大写，这是为了后续查询和比对不出纰漏。status字段直接决定了一辆车当前处于什么阶段，也是后面做并发控制的核心依据之一。
计费规则表我用了"规则主表 + 时段明细子表"的模式。主表保存规则名称、免费时长、每日封顶、适用车辆类型等通用属性，子表保存分时费率。之所以拆开，是因为很多计费方案是分时段的，比如"8:00-20:00按2元/小时，20:00-次日8:00按1元/小时"，用子表一行行存，配置起来最直观。设计的时候再给规则加一个状态字段，启用的规则才参与计费，避免配置到一半被线上读到。
支付订单表pay_order的核心字段要包含record_id、fee_amount、pay_channel、transaction_id、pay_status。这里有一个非常重要的点：transaction_id（第三方支付流水号）必须加唯一索引，这是支付回调幂等的基础，后面章节我详细说。
2.3 订单状态机的流转边界
状态机是整个系统里最容易"埋雷"的地方。我定义了下面这几种状态，并用一个表来约束流转关系：
| 当前状态 | 触发事件 | 下一状态 | 说明 |
|---|---|---|---|
| 在场(0) | 车辆出场，费用计算完成 | 待支付(1) | 临时车出场生成费用 |
| 在场(0) | 月租车/内部车识别成功 | 已支付离场(2) | 不做支付直接放行 |
| 待支付(1) | 支付成功回调 | 已支付离场(2) | 正常流程 |
| 待支付(1) | 管理员手工免费放行 | 已支付离场(2) | 金额置为0 |
| 待支付(1) | 支付超时/现场纠纷 | 异常(3) | 需人工介入 |
| 已支付离场(2) | 收款后退款 | 已退款(4) | 退款需记录操作人 |
状态的迁移逻辑必须收敛在Service层的几个方法里，不要在Controller、定时任务、回调里各自写updateStatus，否则状态会乱成一锅粥。我会尽量把"改状态"收敛到ParkRecordService中的entry、calculateFee、payCallback、manualRelease这几个方法里，一来方便维护，二来方便加事务和分布式锁。
3. 计费引擎：把"算钱"做成一个不随时改代码的模块
3.1 用策略模式组织计费规则
计费模块我最开始也想用一堆if-else写，但整理完需求后发现完全行不通：规则组合太多了，每种规则的计算逻辑都不一样，还有叠加关系。最后采用策略模式，把"按规则算钱"抽象成一个接口，每个计费算法实现一个策略类，再通过规则配置表中的rule_type字段来路由到对应策略。
核心接口非常简单：
public interface FeeCalculator { /** * 计算停车费用 * @param rule 计费规则配置 * @param entryTime 入场时间 * @param exitTime 出场时间 * @return 计算后的费用结果对象，包含金额和计算明细 */ FeeResult calculate(FeeRule rule, LocalDateTime entryTime, LocalDateTime exitTime); }临时车计费、夜间包时段、按次计费这三种实现类，分别对应DEFAULT_HOURLY、NIGHT_PACKAGE、FIXED_ONCE三种规则类型。计算逻辑本身是通用的，可变的是规则参数。这样做的好处是，某天运营方说"夜间包时段从20点改成21点开始"，管理员只需要在后台把规则的生效时间改一下，完全不需要动代码。
3.2 三个最容易被算错的场景：跨天、封顶、免费时长
第一个是跨天拆分。一辆车从昨天23:50停到今天00:30，总时长40分钟。如果直接按总时长算，按"首小时10元"收一次没问题；但如果规则是"白天按小时计费，夜间按一口价"这类分时段方案，就必须把时间按自然日边界（00:00）拆成两段分别计算再合并。我实现的方式是写一个splitByDay方法，把入场时间和出场时间按天切成若干个时间片，每个时间片独立计算。
第二个是封顶金额的判断。"24小时封顶30元"这个规则看上去简单，但要注意封顶是按入场时间开始算24小时，还是按自然日算。实际运营中通常两者都有需求。我的做法是：先按自然日拆分每天的金额，再对每天的金额封顶，然后判断"入场时间+24小时"应该有一个整体封顶，两者取合理规则。具体采用哪套，必须和停车场运营方确认清楚，不能在代码里自行猜测。
第三个是免费时长。比如"入场15分钟内免费"，出场时如果时长不超过15分钟，应收金额为0。但这里要注意：即使金额为0，也还是要生成一条待支付订单，并标记为已完成，否则报表统计车流量时会漏掉这部分车辆。我在计算方法的入口处专门做了这个处理，免费离场车辆一样走完流程，只是费用为0。
3.3 用可注入的时钟来测试计费算法
计费算法最怕的就是"没法测"。如果代码里到处是new Date()，你要验证跨天逻辑就得真等到半夜，或者把系统时间改了，非常痛苦。我的做法是在项目里放一个自定义的TimeProvider组件，默认实现返回LocalDateTime.now()，测试时可以替换成固定时间。
这样就能构造出各种边界用例，比如"入场时间正好是23:59:59，出场是00:00:01"、"时长刚好等于免费时长"、"入场时长超过24小时但每天封顶"。每个用例我都写了对应的单测，同一套用例在后期改规则时也能回归验证。这里我强烈建议，凡是涉及金额计算的代码，必须有单元测试兜底，否则一次改规则改错了，线上跑几天都发现不了。
4. 出入场流程与并发控制：防重复、防白嫖、防算错
4.1 入场流程：先查询校验，再决定放不放行
入场流程不是简单的"拍个照、开闸"就完事。正常顺序是：摄像头识别车牌 → 系统查询该车牌是否存在有效的月租卡或内部车权限 → 如果没有权限，按临时车正常入场 → 开闸 → 写入场记录。如果车是月租车但已经过期，要在现场大屏或岗亭客户端上给出明确提示；如果是黑名单车辆，可以配置不自动抬杆，让保安人工处理。
写入场记录这一步，我建议把car_type和rule_id都算好存下来，而不是等出场再算。因为规则可能在中途被运营方调整，如果入场时用了2元/小时的规则，出场时系统改成了3元/小时，你按哪个算都会引起纠纷。实际操作中常见的做法是"入场绑定规则，出场按绑定规则算"，或者"完全按出场时的最新规则计算，入场只存档当时的规则快照"。我最终选择了后者，也就是规则主键存下来，出场时读取快照来计算，保证同一笔业务前后计算口径一致。
4.2 如何拦住"重复入场"和"重复出场"
真实场景里，会遇到两辆外观一样的车、识别错误、或者套牌车在很短时间内连续入场。如果不做控制，系统里会出现同一个车牌多个"在场"状态的记录，出场时就不知道拿哪条记录去结算了。我在设计时定了一条硬规则：一个车牌在同一时刻只能有一条status=0（在场）的活跃记录。
技术上我先用Redis实现了一个简单的锁，键名设计为park:entry:{plateNo}。入场时先尝试获取锁，拿到锁之后再次查询数据库确认没有在场记录，然后才写入新的入场记录。整个过程是一个原子操作，伪代码如下：
String lockKey = "park:entry:" + plateNo; Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(10)); if (Boolean.TRUE.equals(locked)) { try { // 再次校验在场记录 long activeCount = parkRecordMapper .selectCount(new LambdaQueryWrapper<ParkRecord>() .eq(ParkRecord::getPlateNo, plateNo) .eq(ParkRecord::getStatus, 0)); if (activeCount > 0) { throw new BizException("该车辆已在场内，禁止重复入场"); } // 写入新的入场记录 parkRecordMapper.insert(buildEntryRecord(plateNo)); } finally { redisTemplate.delete(lockKey); } }这里有几个容易踩的坑：锁的过期时间不能太长，否则业务执行完之前锁提前过期，后面的重复请求又进来了；也不能太短，否则业务没做完锁就没了。对于单次入场操作，十几秒的过期时间完全够用，但为了更稳妥，生产环境可以用看门狗自动续期方案。另外用setIfAbsent加分布式锁，释放的时候要判断是不是自己加的锁，避免误删别的请求的锁，这一点在第6章我详细讲。
4.3 出场结算与支付回调的幂等处理
出场流程要处理的时序是：识别车牌 → 查在场记录 → 后台实时计算费用 → 展示给用户 → 用户扫码支付 → 支付平台回调 → 更新订单状态 → 开闸放行。
这里有两个关键点。第一，前端展示的金额只能作为参考，入库和最终结算一定要以后端重新计算为准，不能信任前端传过来的feeAmount。原因很简单，前端报文可以随便改，以后端为准才不会出现"用1分钱出场"的情况。
第二，支付回调必须是幂等的。同一个支付请求，微信/支付宝可能会通知多次，如果每次回调都执行一次"改状态"操作，轻则重复更新，重则状态被覆盖。我的做法是在pay_order表对transaction_id加唯一索引，收到回调时先根据transaction_id查询，如果订单已经是"已支付"状态就直接返回成功，不再重复处理；如果是新回调，就在一个事务里执行"更新订单状态+更新车辆记录状态"。
5. 管理端与统计报表：让系统能真正拿到"日结数据"
5.1 管理端核心页面：在线车辆、规则配置、异常订单处理
管理端不是随便做个CRUD页面就行，真正运营时最常用的是三个模块：在线车辆监控、计费规则配置、异常订单处理。
在线车辆页面主要展示当前场内所有"在场"状态的车辆，包括车牌、入场时间、已停车时长。这个页面需要定时刷新，我最初用的是前端轮询，每5秒拉一次接口，数据量不大时体验完全没问题。如果停车场规模较大，也可以用WebSocket推送，但会增加复杂度，小项目没必要。
规则配置页面是管理端的核心，要能让运营人员直接改"免费时长""首小时费用""后续时长费用""每日封顶"，修改后必须校验数值合法性，比如免费时长不能为负数、后续单价不能高于首小时单价等。每次修改要记录操作日志，方便后期追溯。这里我还做了一个"规则生效时间"的概念，支持配置"从明天8点开始执行新价格"，而不是保存后立刻生效，避免高峰期改价引起现场混乱。
异常订单模块处理的是各种账实不符的情况。比如车辆出场时因为某种原因没有支付成功，管理员可以在后台手工"免费放行"或者"改价后放行"；再比如车辆入场时设备故障没有生成记录，离场时系统查不到在场记录，管理员可以手工补一条入场记录。这些操作都要记录操作人、操作时间和原因，做到事后可审计。
5.2 报表统计的SQL思路与缓存策略
报表是停车场运营方最看重的功能，每天结束时要对账。我实现了"当日收入汇总""月收入趋势""车流量统计""高峰时段分布"这几个核心报表。
当日收入汇总最简单，一个SQL就能搞定：
SELECT DATE(create_time) AS day, COUNT(*) AS order_count, SUM(fee_amount) AS total_income FROM pay_order WHERE pay_status = 'PAID' AND create_time >= ? AND create_time < ? GROUP BY DATE(create_time) ORDER BY day DESC;车流量统计则按入场时间分组，看一天中哪个时段最忙，对停车场设置出入口方向、安排安保人员都有参考价值：
SELECT HOUR(entry_time) AS hour, COUNT(*) AS entry_count FROM park_record WHERE entry_time BETWEEN ? AND ? GROUP BY HOUR(entry_time) ORDER BY hour;数据量小的时候实时查没问题，但运行几个月后流水表会越来越大，每次报表都全量扫描会很慢。我的做法是加了一个定时任务，每天凌晨把前一天的订单聚合结果写入一张daily_report汇总表，报表页面优先读汇总表，只有需要看明细时才走流水表查询。另外，把热门的报表接口加上Redis缓存，设置几分钟过期，也能显著降低数据库压力。
6. 上线前我排查过的几个典型Bug与处理记录
6.1 时间精度与时区导致"出场时间早于入场时间"
第一次联调时，我遇到了一个诡异的问题：页面展示的停车时长是负数，出场时间竟然比入场时间还早。排查了很久，发现根因有两层：第一，管理端前端页面用字符串把时间传到后端，格式没有严格校验；第二，数据库连接串里的时区参数配错了，导致存入的时间被偏移了8小时，入出场时间一个按UTC存一个按本地时间解析，直接错乱。
修复方案是：统一后端使用LocalDateTime，前端传时间戳或固定格式的字符串，数据库连接串加上serverTimezone=Asia/Shanghai，所有的时间字段在入库前都要经过同一个TimeProvider统一校准。这个Bug让我意识到，停车计费这种对时间高度敏感的系统，时间和时区必须从一开始就统一约定，不然后面每个功能都会被它坑一遍。
6.2 并发测试时出现的重复入场记录
我用JMeter做了个简单压测，模拟20个线程同时提交同一个车牌的入场请求，结果数据库里出现了两条"在场"状态的记录。原因就是我在4.2节说的：多个请求同时通过"查询在场记录"的校验，然后再同时写入，查询那一步根本拦不住并发。后来加上Redis锁之后，同一时刻只允许一个入场请求进入临界区，重复记录就不再出现了。
另外说一个我在这个过程中踩的坑：最早我写释放锁的逻辑是直接在finally里redisTemplate.delete(lockKey)，结果有一次A请求的锁刚过期，B请求立刻拿到新锁开始处理，A请求结束时把B的锁删了，导致C请求又进来了。后来我改成"锁的value存一个唯一ID，删除前比较一下是不是自己的ID"，这个问题才解决。这种细节在教科书里不会讲，但线上一定会遇到。
6.3 BigDecimal用错了构造方式，一分钱对不上账
计费金额一开始我用的是BigDecimal.valueOf(amount)，后来某次测试发现有些订单金额出现精度误差，排查半天才发现是自己写的一段代码用了new BigDecimal(3.0)，直接把double的二进制误差带进了金额计算。BigDecimal的推荐用法是传入字符串或者使用BigDecimal.valueOf，new BigDecimal(3.0)这种写法必须避免。数据库里金额字段统一用DECIMAL(10,2)，Java里金额对象全部复用同一个BigDecimal工具类，禁止散落各处直接new，这样才能保证"算出来的钱"和"账单上的钱"永远一致。
6.4 设备异常时的兜底方案不能省略
上线前我一度认为摄像机识别率很高、道闸很稳定，不需要太多异常处理。结果现场调试时发现，雨天、夜间逆光、车牌脏污都会导致识别失败，偶尔还会出现道闸开了但系统没收到开闸成功回执的情况。这让我意识到设备异常不是"万一""偶然"，而是日常运营的一部分。我给系统加了手工入场、手工出场、免费放行、无牌车扫码入场这几个人工兜底功能，同时把"开闸失败是否允许重试""识别失败后允许人工输入车牌"这些规则都做到了后台配置里。开发阶段觉得这些功能"不技术"，但上线后运维人员靠这些功能才能把现场撑起来。
最后再分享一点我个人的体会：这类系统很容易被人低估，觉得无非就是"一个管理后台加几个接口"。但真正做完你会发现，最花时间的不是CRUD，而是把业务规则想清楚、把边界状态都兜住。如果你也正在做停车计费相关项目，我的建议是先花两天时间把本章列出的这些业务场景和边界情况整理成一份清单，再动手写代码，后面会轻松非常多。
