基于SSM框架与Vue的智能停车管理系统开发实战解析-开发者社区

这两年停车管理系统的需求涨得很猛，从小区物业到商业综合体，都在找一套能支撑日常运营的智能停车方案。我之前给一个模拟项目X做过一套基于SSM框架智能停车系统，前端配合Vue，从车位预约、进场识别到出场结算全流程打通，实测下来效果稳定，接了几个月的真实业务数据也没出过岔子。这篇文章就把这套系统的完整实现思路、核心代码逻辑、踩过的坑和排查方法一次性说清楚，想自己动手做停车管理系统的朋友可以直接参考。

1. 整体设计与技术选型思路

1.1 为什么选SSM+Vue这套组合

先聊一下技术选型的底层逻辑。智能停车系统本质上是一个典型的管理类业务系统，核心动作是数据的增删改查、状态的流转控制、费用的实时计算。这类系统最怕的不是功能做不出来，而是后期维护和扩展的时候被技术栈绑架。

SSM（Spring + Spring MVC + MyBatis）这套组合在Java生态里算是久经考验的经典方案。Spring负责对象管理和事务控制，把Service层的业务逻辑和DAO层的数据访问解耦开；Spring MVC处理前端的请求分发和参数绑定，让Controller层的代码保持清爽；MyBatis则把SQL操作和Java方法做了映射，复杂的多表联查写起来非常灵活。这三者配合，开发效率高，而且社区资料极度丰富，遇到问题基本都能搜到现成答案。

前端选择Vue则是出于实际体验的考虑。停车系统的管理端需要实时展示车位占用情况、进出记录、收入统计等动态数据，如果用传统的服务端渲染页面，每一次数据变化都要刷新整个页面，操作体感很差。Vue的数据双向绑定特性让视图和状态保持同步，用户操作反馈即时，体验和开发效率都比传统jsp方案高出一大截。

这套前后端分离的架构还有一个隐蔽的好处：后端接口做好权限校验后，以后想接小程序、App客户端，只需要复用已有的API接口就行，不需要动后端代码。

1.2 系统功能模块拆解

整个系统按使用角色拆分，主要包含三个端：用户端小程序、管理员后台、岗亭值守端，我这里后端统一提供服务，前端用Vue分别构建了管理后台H5和商户端页面。

核心功能模块如下：

车位管理模块：车位信息维护、车位状态实时更新（空闲/占用/预约）、车位锁定与释放
车辆管理模块：车牌信息登记、车辆类型区分（临时车/月租车/VIP车）、黑名单管理
预约停车模块：用户提交预约申请、系统自动匹配车位、预约时段管理、超时处理
进出管理模块：车辆入场登记、出场结算、收费规则引擎
用户管理模块：车主信息管理、余额充值、消费记录查询
数据统计模块：今日营收、车流量趋势、车位利用率、收费类型分布

这些模块之间的数据流关系是：车位管理为预约模块提供可预约资源，车辆入场后车位从“空闲”变为“占用”，出场结算时根据停车时长和车辆类型计算费用，最后所有记录汇总到统计模块。

2. 数据库设计与核心表结构

2.1 数据模型设计思路

停车系统的数据模型相对标准，但有几个设计细节值得单独拿出来讲。

第一点是计费逻辑的数据支撑。停车费用计算必须要有“计时规则”和“计费规则”两个维度。计时规则指按分钟计费还是按小时计费，计费规则指单价是多少、封顶价是多少、免费时长多长。我把这些参数单独抽了一张收费规则表，而不是写死在代码里，这样运营方想调整价格，直接在后台改配置就能生效，不需要发版。

第二点是车位状态的数据一致性。车位的“占用”“预约”“空闲”状态是高频变动的数据，我设计了单独的停车记录表实时记录每一次占用周期，车位表里只保存一个当前状态字段。这样如果某一天的记录数据异常，可以基于停车记录表重新校正车位状态，不会出现数据错乱的脏数据。

2.2 关键表结构详解

核心表我设计了六张：车位表、车辆表、收费规则表、停车记录表、预约记录表、用户表。

车位表字段如下：

CREATE TABLE parking_space ( id BIGINT PRIMARY KEY AUTO_INCREMENT, space_no VARCHAR(20) NOT NULL COMMENT '车位编号', area VARCHAR(50) COMMENT '所属区域', status TINYINT DEFAULT 0 COMMENT '0=空闲 1=占用 2=预约', is_private TINYINT DEFAULT 0 COMMENT '是否私有车位', owner_id BIGINT COMMENT '固定车位车主ID', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

停车记录表是业务核心，设计时我特意加了几个冗余字段。

CREATE TABLE parking_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, record_no VARCHAR(32) NOT NULL COMMENT '流水号', plate_number VARCHAR(20) NOT NULL COMMENT '车牌号', space_id BIGINT NOT NULL COMMENT '车位ID', car_type TINYINT DEFAULT 0 COMMENT '0=临时车 1=月租车', entry_time DATETIME NOT NULL, exit_time DATETIME, duration_minutes INT COMMENT '停车时长分钟', total_amount DECIMAL(10,2) COMMENT '应收金额', pay_status TINYINT DEFAULT 0 COMMENT '0=未支付 1=已支付', pay_time DATETIME, operator VARCHAR(50) COMMENT '操作员', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

冗余字段的设计逻辑是：停车时长和应收金额在出场结算时一次算好存下来，后续统计报表直接查这两个字段就行，不用反复重算历史记录。

2.3 收费规则表设计思考

收费规则表我采用了“规则类型+规则参数”的设计方式：

CREATE TABLE charge_rule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, car_type TINYINT COMMENT '车辆类型', rule_type TINYINT COMMENT '0=按时段 1=按时长 2=按次数', free_minutes INT DEFAULT 15 COMMENT '免费时长', unit_minutes INT DEFAULT 60 COMMENT '计费单位', unit_price DECIMAL(10,2) DEFAULT 0 COMMENT '单价', cap_amount DECIMAL(10,2) DEFAULT 0 COMMENT '单次封顶', rule_name VARCHAR(50) );

比如一个典型商业停车场规则：首小时免费，超过1小时后按每小时5元计费，不足1小时按1小时算，单日封顶30元。这种规则直接映射到表里就是：free_minutes=60，unit_minutes=60，unit_price=5.00，cap_amount=30.00。后期加“夜间优惠”“周末特惠”等复杂规则，只需要增加规则行并设置生效时段就行。

3. 核心业务逻辑与接口实现

3.1 车位预约流程的实现

预约流程是这套系统里比较能体现业务逻辑的模块。用户端提交预约请求到后端，后端需要完成三个步骤：校验用户身份、查找空闲车位、锁定车位创建预约订单。

核心逻辑代码如下：

@Service public class ReserveServiceImpl implements ReserveService { @Autowired private ParkingSpaceDao parkingSpaceDao; @Autowired private ReserveRecordDao reserveRecordDao; @Transactional(rollbackFor = Exception.class) public ResultVO createReserve(ReserveRequest req) { // 1. 参数校验 if (StringUtils.isBlank(req.getPlateNumber())) { return ResultVO.error("车牌号不能为空"); } // 2. 查询空闲车位，使用悲观锁防止并发抢占 ParkingSpace space = parkingSpaceDao.selectFreeSpaceByArea( req.getAreaId(), req.getStartTime(), req.getEndTime()); if (space == null) { return ResultVO.error("当前时段无空闲车位"); } // 3. 更新车位状态为预约 int rows = parkingSpaceDao.updateStatus(space.getId(), 0, 2); if (rows == 0) { return ResultVO.error("车位已被抢占，请重新选择"); } // 4. 创建预约记录 ReserveRecord record = new ReserveRecord(); record.setPlateNumber(req.getPlateNumber()); record.setSpaceId(space.getId()); record.setStartTime(req.getStartTime()); record.setEndTime(req.getEndTime()); record.setStatus(0); // 待入场 reserveRecordDao.insert(record); return ResultVO.success("预约成功"); } }

事务注解必须加在 createReserve 方法上，这样“更新车位状态”和“创建预约记录”两个步骤要么同时成功要么同时回滚，避免出现车位状态改了但预约记录没生成的情况。

3.2 进场识别与入场登记

车辆入场是整套系统中的数据入口。实际部署的时候，入口处的摄像头识别车牌后，调用后端接口登记入场信息。

入场接口有几个隐蔽的坑需要处理。第一个是重复入场问题：同一位车主刚出场就又进场，或者摄像头误识别导致短时间内同车牌两次入场请求。我在入场接口里做了防重处理，通过Redis判断该车牌是否有未完结的停车记录，有的话直接返回重复入场提示，不再创建新记录。第二个是黑名单校验：入场时必须检查车辆是否在黑名单中，如果是黑名单车辆，系统拦截放行还是人工处理的配置取决于物业需求。第三是非机动车放行问题，摄像头有时候会误触发，必须校验车牌号格式，不符合车牌规则的直接过滤掉。

入场逻辑核心代码如下：

public ResultVO carEntry(String plateNumber, Long spaceId) { // 1. 防重复入场检查 ParkingRecord activeRecord = parkingRecordDao.selectActiveByPlate(plateNumber); if (activeRecord != null) { return ResultVO.error("该车辆已有入场记录，请勿重复入场"); } // 2. 黑名单校验 if (blacklistDao.existsByPlate(plateNumber)) { return ResultVO.error("该车辆在黑名单中，请联系管理员处理"); } // 3. 创建入场记录 ParkingRecord record = new ParkingRecord(); record.setRecordNo(generateRecordNo()); record.setPlateNumber(plateNumber); record.setSpaceId(spaceId); record.setEntryTime(new Date()); record.setPayStatus(0); parkingRecordDao.insert(record); // 4. 车位状态置为占用 parkingSpaceDao.updateStatus(spaceId, 0, 1); return ResultVO.success("入场成功"); }

generateRecordNo 生成流水号的规则可以自由设计，我采用“yyyyMMddHHmmss + 四位随机数”的组合，保证并发场景下流水号基本不会重复，后续对账也方便按时间维度筛选。

3.3 出场结算与费用计算

出场结算是最容易出问题的地方，核心难点在费用计算的准确性。我按“取整向上”和“分段计费”两种模式都实现过，最后根据业务需要选择了先分段后取整的模式。

费用计算的实现代码如下：

public BigDecimal calculateFee(ParkingRecord record) { long minutes = (System.currentTimeMillis() - record.getEntryTime().getTime()) / 60000; if (minutes <= 0) { minutes = 1; } // 查询该车辆类型对应的收费规则 ChargeRule rule = chargeRuleDao.selectByCarType(record.getCarType()); // 免费时段 if (minutes <= rule.getFreeMinutes()) { record.setDurationMinutes((int) minutes); return BigDecimal.ZERO; } // 扣除免费时长后的计费时长（单位分钟，向上取整） int billableMinutes = (int) minutes - rule.getFreeMinutes(); int billableUnits = (int) Math.ceil(billableMinutes / (double) rule.getUnitMinutes()); BigDecimal amount = BigDecimal.valueOf(billableUnits) .multiply(rule.getUnitPrice()); // 封顶逻辑 if (rule.getCapAmount() != null && rule.getCapAmount().compareTo(BigDecimal.ZERO) > 0 && amount.compareTo(rule.getCapAmount()) > 0) { amount = rule.getCapAmount(); } record.setDurationMinutes((int) minutes); return amount; }

这里有个重要的细节：计算金额一定要用 BigDecimal，不能用 double 或 float，否则金额小数计算会出现精度丢失，跑上几万条记录后对不上账是必然的事。另外，免费时长到底怎么扣除，不同停车场的算法不同，有的是“一次性扣除一次性免费时长”、有的是“每超出一定时长再送免费时长”，我在系统里做了一个开关配置，灵活应对不同场景。

3.4 停车券与优惠抵扣

停车券这个模块虽然小，但是在实际运营中很关键。商业综合体的停车场经常有消费满减停车费的活动，如果没有停车券功能，运营就得人工按零钱结算，体验很差。

我设计了一张优惠券表，核心字段包括：券码、面额、使用状态、绑定车牌、有效期。出场结算时，如果停车记录关联了优惠券，先计算应收金额，再减去优惠券面额，实收金额做二次校验必须是非负数。

public ResultVO settleAndPay(String recordNo, String couponCode) { ParkingRecord record = parkingRecordDao.selectByRecordNo(recordNo); if (record == null) { return ResultVO.error("停车记录不存在"); } if (record.getPayStatus() == 1) { return ResultVO.error("该订单已支付"); } BigDecimal amount = calculateFee(record); // 优惠券抵扣 if (StringUtils.isNotBlank(couponCode)) { Coupon coupon = couponDao.selectByCode(couponCode); if (coupon == null || coupon.getStatus() != 0) { return ResultVO.error("优惠券无效或已使用"); } if (coupon.getExpireTime().before(new Date())) { return ResultVO.error("优惠券已过期"); } if (coupon.getPlateNumber() != null && !coupon.getPlateNumber().equals(record.getPlateNumber())) { return ResultVO.error("优惠券与当前车牌不匹配"); } amount = amount.subtract(coupon.getAmount()); if (amount.compareTo(BigDecimal.ZERO) < 0) { amount = BigDecimal.ZERO; } // 原子更新优惠券状态，防止并发重复使用 int rows = couponDao.markUsed(coupon.getId(), recordNo); if (rows == 0) { return ResultVO.error("优惠券已被使用"); } } // 更新停车记录 record.setTotalAmount(amount); record.setPayStatus(1); record.setPayTime(new Date()); parkingRecordDao.updateSettled(record); return ResultVO.success("结算成功", amount); }

优惠券状态更新这里用了一个SQL原子更新：UPDATE coupon SET status=1, use_record_no=? WHERE id=? AND status=0，这一步非常关键。如果先查再改，并发场景下同一张券会被两个订单同时用掉，跑一次压测就能复现这个问题。

4. 数据可视化统计模块实现

统计模块是运营方关注度最高的部分。我刚上线第一版的时候只做了几个简单数字展示，运营反馈不好用，后来重新设计了统计维度。

当前版本包含四个核心指标看板：

今日营收总览：显示今日应收、实收、优惠抵扣三组数字，并显示较昨日的环比变化
车流量趋势图：按小时维度展示进场和出场车次，运营可以直观看到高峰时段
车位利用率热力图：按区域查看车位占用时间占比，用于评估高峰期车位紧张程度
收费类型分布：临时车、月租车、VIP车各自的停车频次和收入占比

Vue端我用了可视化图表组件库来实现图表渲染。这里有个实际经验：图表数据不要在前端做聚合计算，让后端直接返回处理好的统计结果，前端只做渲染。后端写SQL聚合统计虽然稍微麻烦一点，但数据准确性更有保障，而且大数据量下性能也更好。

趋势图接口的SQL实现思路：

SELECT DATE_FORMAT(entry_time, '%H') AS hour, COUNT(*) AS total FROM parking_record WHERE entry_time BETWEEN #{startTime} AND #{endTime} GROUP BY DATE_FORMAT(entry_time, '%H') ORDER BY hour

返回秒数当然不止这些，实际开发的时候还加了车位利用率、时长分布、月营收趋势等接口，都是按同样的思路做分组聚合，然后返回JSON给前端渲染。

5. 系统安全性与高并发处理

5.1 接口防刷与权限控制

停车系统的接口直接暴露在公网环境中，防刷和权限控制是必须做好的，不然随时可能被恶意请求打爆或者数据泄露。

我的做法是三层防护。第一层是Spring MVC拦截器统一做JWT Token校验，所有业务接口都必须携带有效Token才能访问。第二层是接口级权限控制，管理员接口和普通用户接口分开，通过用户的角色字段做二次校验。第三层是IP级别的访问频率控制，用Redis存储每个IP在固定时间窗口内的请求次数，超过阈值就临时封禁。

public class RateLimitInterceptor implements HandlerInterceptor { @Autowired private RedisTemplate<String, Integer> redisTemplate; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String ip = getClientIp(request); String key = "rate_limit:" + ip; Integer count = redisTemplate.opsForValue().get(key); if (count == null) { redisTemplate.opsForValue().set(key, 1, Duration.ofMinutes(1)); } else if (count >= 100) { throw new RateLimitException("请求过于频繁，请稍后再试"); } else { redisTemplate.opsForValue().increment(key); } return true; } }

这套限流方案虽然简单，但对停车系统这种并发量不算极端但经常有突发小高峰的场景，完全够用。

5.2 高并发下车位状态一致性问题

停车系统里最典型的高并发场景是：多个用户同时预约同一个车位，或者入口摄像头同时发起入场请求。如果不加控制，数据库层面的数据就可能不一致。

解决思路是数据库行锁。MyBatis做“状态查询+更新”不是原子操作，所以我把“查询空闲车位并更新状态”合并成一条SQL：

UPDATE parking_space SET status = 1 WHERE id = #{spaceId} AND status = 0

这条SQL如果影响行数为0，说明这个车位已经被别人更新了，并发请求自然不会执行成功。这样从源头保证了车位状态不可被并发覆盖。配合MySQL默认的行锁机制，即使同一时刻来了10个预约请求，最终也只有一个能成功。

这套机制的缺点是牺牲了一点吞吐量，但在停车位预约这种低频小规模事务场景下，可靠性远比吞吐量重要。

5.3 数据备份与异常恢复

停车系统的数据是运营方的核心资产，一旦丢了没有任何办法补回。我制定了每日全量备份、每小时增量备份的节奏，备份文件通过定时任务推送到异地存储。

某次真实演练时发现一个之前没注意的细节：MyBatis的批量插入在某个低版本驱动下，如果插入记录中包含空字符串，会偶尔报异常。为了稳定，我在插入记录前统一做了空值转默认值的预处理。

此外，系统里还接了一个健康检查接口，监控服务所在环境的磁盘空间、内存使用率、数据库连接池状态。如果某台环境上的磁盘占用率超过85%，系统自动发告警，运维可以直接定位到是数据库日志文件增长过快，还是服务器上其他进程占用空间。

6. 常见问题与排查技巧实录

6.1 部署环境问题：数据库连接池溢出

上线后第一周，某次下班高峰时段，系统突然出现大量“获取连接超时”的报错。当时第一反应是并发量太高把数据库连接池打爆了。

排查过程分三步。第一步，查看数据库最大连接数配置，确认数据库端连接数上限不是瓶颈。第二步，查看服务日志中连接池等待超时的堆栈信息，发现绝大多数超时请求都卡在一个查询操作上。第三步，打开数据库慢查询日志，定位到一条车位统计SQL。

问题根因是那条统计SQL在parking_record表没建索引的情况下做了全表扫描，数据量达到几十万条后执行耗时飙升，连接长时间被占用不释放。解决方法是给entry_time、plate_number两个字段建联合索引，优化后慢查询日志再也没出现过这条SQL。

经验总结：上线前一定要用接近真实量的数据做压测，不要只在小数据量下验证功能正确。

6.2 前端展示问题：车位状态不同步

Vue端的一个偶发问题是车位列表显示状态和实际不一致，某车位明明已有车辆入场，界面上还是显示空闲。

排查后发现是WebSocket消息推送链路出了问题。后端车位状态变化时，通过WebSocket向前端推送通知，前端收到通知后刷新对应车位状态。但某次后端服务重启后，WebSocket连接断了却没有自动重连，前端一直沿用旧的连接，后续状态变化推送全部丢失。

修复方案是前端增加心跳检测和断线重连机制，后端增加连接状态监控，异常断开时主动清理失效连接。后来在系统运行中，开发环境重启服务时还观察到WebSocket会自动重连的日志信息，验证了修复生效。

6.3 业务问题：跨天停车计费多算

这是运营方反馈的一个真实bug：某车辆前一天晚上入场，第二天上午出场，收费金额比人工计算多了几个小时。

查日志后定位到问题出在计费规则的“封顶逻辑”上。单日封顶是指自然日内的封顶，而我的实现把跨天的停车记录当成一段连续时长计算，直接从入场到出场累计计时，导致跨午夜时段的费用超过了两个自然日各自的封顶之和。

修复方案是对跨天停车记录做“分段计费”处理，按自然日拆分为多段，每段单独封顶再累加。这个逻辑我封装成了一个工具方法，后来月租车和临时车混合计费时也复用了这套分段逻辑。

6.4 支付回调问题：重复通知导致重复入账

对接支付平台回调的时候，出现过支付平台重复推送回调通知导致停车记录重复入账的问题。一开始是在回调处理接口里加了一个查询校验，但并发场景下还是偶尔重复。

后来改为数据库唯一键约束兜底。在停车记录表上对record_no字段建了唯一索引，重复回调尝试插入同一条记录时数据库直接拒绝，程序捕获主键冲突异常后返回成功响应，不再重复入账。

这类幂等性问题在支付相关模块里特别常见，所有写操作都必须考虑重复调用的场景。

7. 部署上线与运营维护心得

这套SSM+Vue架构的智能停车系统，持久层用的MySQL存储业务数据，缓存层用Redis处理热点数据，部署上采用前后端分离、单机起步的模式，后续可以无缝扩展。如果预计并发量会持续增长，建议提前规划Nginx负载均衡和数据库主从读写分离。停车系统这种业务属于典型的读多写少，主库负责写入停车记录和状态更新，从库负责统计查询和报表展示，对日常运营帮助很大。

从框架配置到上线运营，有几个配置项值得注意：