Spring Boot商场停车场预约服务管理信息系统设计与实现

工作日早高峰的商场停车场，入口排长队、地库转圈找车位——这个场景我相信每个开车去商圈的人都经历过。问题本质就两个：入口车道吞吐量不够，场内车位信息不透明。车主不知道哪有空位，只能漫无目的地转；管理方不知道谁会来、什么时候来，只能被动等车进场。这个"springboot175基于springboot商场停车场预约服务管理信息系统"，要解决的正是这两个核心痛点。

先说清楚这是个什么东西。它是一个基于Spring Boot搭建的B/S架构系统，面向商场停车场场景，让车主可以提前查看车位余量、在线预约停车时段、生成入场凭证，同时让停车场管理方可以配置预约规则、管理车位状态、查看经营数据。说白了，就是把传统停车场的"随到随停、碰运气"模式，改造成"先约先得、错峰入场"的预约制模式。

如果你是正在做毕业设计的学生，或者想用一个真实业务场景来练手Spring Boot全栈开发，又或者你在物业、停车管理相关行业工作，想了解预约系统的技术实现思路——这篇文章都适用。我会从需求拆解、技术选型、数据库设计、核心业务逻辑到实际踩坑，完整讲一遍这个系统的构建过程。

1. 项目整体定位与需求拆解

1.1 预约制解决了什么核心问题

停车场的收入公式很简单：收入 = 车位数 × 周转率 × 单位时间收费。在车位总数不变的前提下，想提高收入只能提高周转率。而传统停车场的周转率受两个瓶颈制约：

入口瓶颈。早高峰所有车同时涌入，每辆车进场需要取卡或识别车牌，平均耗时10到20秒，入口车道数量有限，排队自然发生。预约制把入场需求分摊到不同时段，相当于做了一个削峰填谷，把瞬时并发转为平稳流量。

信息瓶颈。车主不知道场内哪里有空位，进去了也找不到，造成无效巡游。预约制通过系统提前锁定车位资源，每个时段的可预约数就代表该时段的实际接纳能力，信息透明了，车主决策也快了。

这个系统在业务上还有一个关键设计——错峰定价。工作日白天停车需求低，可以设置低价甚至免费时段吸引周边上班族；节假日和周末需求高，预约费用上浮。价格杠杆让有限的车位资源在不同时段之间自动调配，管理方不用手动干预。

1.2 用户角色与功能边界

一个完整的商场停车场预约系统，至少要涵盖三类用户，各自有完全不同的操作界面和权限范围。

车主端（小程序或H5）：

• 注册登录、绑定车牌号（一个账号可以绑定多辆车）
• 按时间、位置查询可预约车位，看实时余量
• 在线预约、取消预约、支付预约费用
• 预约成功后生成入场二维码
• 查看历史订单、停车记录、缴费记录

停车场管理端（Web后台）：

• 车位管理：维护车位编号、区域、类型（普通/无障碍/充电桩）
• 预约规则配置：可预约时段、每时段可预约数量、提前预约天数、预约取消时限
• 订单管理：查看所有订单、处理异常订单、手动释放车位
• 基础数据维护：收费规则、商户信息

系统运营端：

• 数据统计：分时段入场量、预约转化率、车位利用率
• 报表导出：日/周/月经营报表
• 设备管理：对接道闸、地磁感应、摄像头等硬件设备

我见过不少同类毕业设计项目，功能上往往只做了车主端和管理端，运营端被忽略。但实际业务中，运营端的报表统计恰恰是停车场管理方最看重的功能。做这个项目时，可以把统计报表作为一个独立模块设计，哪怕实现简单一点，也要有。

1.3 核心业务流程梳理

整个系统的业务主线是一条状态流转链路，建议在动手写代码之前先在纸上把它画清楚：

车位状态：空闲 → 锁定 → 已预约 → 已入场 → 已离场 订单状态：待支付 → 已支付 → 已完成 → 已取消 → 已超时

预约的完整流程是这样的：车主查询可预约时段→选择车位和时段→提交预约单→系统锁定车位→车主支付→支付成功后生成入场凭证→车主到场扫码入场→离场后订单完成，车位释放。

这里面有几个容易被忽略的细节。锁定和预约是两件事。提交订单时只是锁定车位，还没占用名额；只有支付成功后才真正占用该时段的名额。锁定期一般设置为15分钟，超时未支付自动释放。这个设计借鉴了12306的购票逻辑，既给车主留足支付时间，又不让恶意占单长期霸占资源。

取消策略也需要想清楚。距离预约入场时间大于2小时，允许无损取消，费用原路退回；小于2小时取消，只退部分费用或不退。这个阈值不是拍脑袋定的，因为停车场管理方需要时间把释放出来的名额再次投放市场，太临近了二次售卖的概率就低。

2. 技术选型解析

2.1 为什么是Spring Boot

这个项目技术栈的核心选择是Spring Boot，这个选择本身没有悬念，但还是要说说理由，因为理解了选型逻辑，后面写代码时思路会更清晰。

Spring Boot的核心价值是降低了Spring应用的搭建成本。传统Spring项目需要手动配置大量的XML文件，配置数据源、事务、MVC、Bean扫描，光搭框架就要折腾一两天。Spring Boot用自动配置和约定大于配置解决了这个问题，一个starter依赖加几行配置就搞定。对于这种面向业务开发的信息管理系统，开发效率是第一位的，框架本身不应消耗过多精力。

另外一个重要原因是生态。商场停车场系统需要对接支付（微信/支付宝）、短信通知、对象存储（车牌照片）、硬件设备（道闸/DVR）等外部服务，这些都有成熟的Spring Boot starter集成方案，文档齐全，遇到问题也能搜到大量真实案例。

有一个偏见我需要纠正一下。不少人觉得"Spring Boot就是SSM换了个壳"，这不对。Spring Boot虽然底层仍然依赖Spring MVC和MyBatis，但它改变了开发模式——内嵌Tomcat让应用可以独立运行，微服务化的基础设施支持让它可以无缝衔接注册中心、配置中心、网关等组件。做这个项目时用单体的方式就够了，但架构边界要清晰，后续拆分成微服务不至于伤筋动骨。

2.2 ORM框架：MyBatis Plus还是Spring Data JPA

这是做这个项目时最先遇到的选择题。我的建议是：用MyBatis Plus。

JPA的优点是用实体对象直接映射表结构，简单场景下少写很多SQL。但停车预约系统涉及大量的动态条件查询（按时间、区域、车位类型筛选可用车位）、复杂的状态流转更新（锁定、释放、入场、离场），这些场景下MyBatis的SQL可控性优势非常明显。MyBatis Plus则在MyBatis基础上封装了通用Mapper和通用Service，单表CRUD基本不用写SQL，同时保留了自定义SQL的能力，两者兼顾。

关键的取舍点是多表关联查询。预约订单列表需要关联查询用户昵称、车牌号、车位编号、区域名称，如果用JPA的Entity关联映射，会引入延迟加载的坑；用MyBatis Plus的@Select注解手动写JOIN SQL，查询结果直接映射到VO对象，逻辑清晰且性能可控。

做这个项目时的依赖配置是这样的：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency>

MyBatis Plus 3.5.x版本支持逻辑删除、自动填充、乐观锁插件，都是这个项目直接能用上的功能。

2.3 Redis在系统中的定位

很多学生做这个项目，Redis只在登录时存个Token，这是对Redis的巨大浪费。停车预约系统的核心业务——实时余量查询、车位锁定、分布式并发控制——每一环都依赖Redis才能扛住实际压力。

实时余量查询。如果每个车主每次刷新余量都去查MySQL，一个500车位的停车场在高峰期每秒可能产生几十次查询，数据库压力大可不必。把"某时段剩余车位数"做成一个可缓存的Key，过期时间设为30到60秒，查询性能提升一个数量级，对实时性的影响微乎其微。

车位锁定。这是Redis在这个项目中最重要的应用。用SETNX命令实现分布式锁，保证同一车位、同一时段只能被一个订单锁定。纯靠数据库的乐观锁也能做，但并发高的时候会有大量请求冲突重试，体验不好。Redis的原子性操作天然适合做这种短时间的互斥控制。

入场凭证管理。预约成功后生成的入场二维码，除了存数据库，在Redis里存一份并设置有效期。道闸扫码时先查Redis，命中则直接放行，不命中再查数据库。这个缓存的命中率非常高，因为预约入场时间通常集中在半小时内。

2.4 认证方案：JWT还是Session

单体应用用Session其实没问题，但考虑到车主端是H5/小程序，管理端是Web，不同端之间需要共享登录态，用JWT更方便。JWT是无状态Token，服务端不保存会话信息，客户端每次请求带Token，服务端验签即可。

这个项目里JWT的实践要点：

• 用户登录成功后签发Token，有效期设为7天，支持自动续期
• Token中只放用户ID和角色，不放敏感信息
• 管理端和车主端用不同的Token密钥，防止越权
• 拦截器校验Token，将用户信息放入ThreadLocal供业务代码使用

JWT有个天然缺陷是无法主动失效。用户修改密码或管理员封禁账号后，已签发的Token在过期前仍然有效。这个项目的处理方案是：把账号状态和Token版本号存入Redis，每次请求时比对版本号，不一致则拒绝。这样既保留了JWT的无状态优势，又解决了主动失效问题。

3. 数据库设计实战

3.1 核心表结构总览

数据库是整个系统的地基，表结构设计得好不好，直接决定后续业务逻辑的实现复杂度。这个项目的核心表一共7张，我列出来并说明每一张的定位：

需要注意的是，先有时段定义表，再谈预约。时段不是写死在代码里的，而是数据库可配置的。这样运营人员可以随时调整时段的配额和价格，不用发版。时段的粒度一般设为30分钟或1小时，太细管理成本高，太粗又达不到错峰分流的效果。

3.2 订单表的字段设计细节

appointment_order是这个系统业务逻辑的核心载体，字段设计需要格外讲究。

订单号：不要用自增ID做业务编号。自增ID会暴露业务量，且在多表联查时容易混淆。用雪花算法生成19位纯数字订单号，客户端和运营后台都用这个编号沟通。

状态字段：用tinyint类型，配一个状态枚举类统一管理，不要存中文状态。试过直接用字符串存状态的方案，查询条件写起来很爽，但代码维护时到处是魔法值，改一个词要全局替换，教训很深刻。

时间字段：预约日期和时间段分开存。appoint_date存日期，time_slot_id关联时段表。为什么不直接存开始时间和结束时间？因为商场停车场按30分钟一个时段运营，预约的配额和价格都是基于时段设置的，分开存才能和配额、定价逻辑对齐。如果存开始结束时间，后面统计每个时段的预约量还得做时间转换，徒增复杂度。

冗余字段：plate_no、zone_name、port_no这些字段在订单表里冗余一份。虽然违反了第三范式，但业务查询列表页时不需要JOIN多张表，性能提升明显。数据量到十万级之后，JOIN的代价会体现在接口响应时间上，冗余字段是常用的空间换时间策略。

还有一个容易被忽略的字段：取消原因。订单取消时记录原因（用户取消、超时未支付、管理端强制释放），后续数据分析时能知道释放的车位是哪种情况，针对性地优化规则。

3.3 状态机设计

停车预约系统的订单状态不适合用一个简单的字段管理，因为状态之间不是自由跳转的。建议单独写一个状态机的枚举类，把所有允许的流转路径定义清楚：

public enum OrderStatusEnum { WAITING_PAY(0, "待支付"), PAID(1, "已支付"), ENTERED(2, "已入场"), FINISHED(3, "已完成"), CANCELED(4, "已取消"), TIMEOUT(5, "已超时"), REFUNDING(6, "退款中"); private final int code; private final String desc; }

状态流转的规则：

• 待支付 → 取消（用户主动取消或超时未支付）
• 待支付 → 已支付（支付成功）
• 已支付 → 已入场（车主扫码入场）
• 已入场 → 已完成（离场结算）
• 已支付 → 取消中 → 已取消（用户取消且退款成功）
• 已支付 → 已入场 → 已完成（正常流程，不允许跳过）

在代码层面，每次更新状态时都要校验当前状态是否符合预期的前置状态。我见过直接写update order set status = 3 where id = xxx的项目，并发场景下状态被覆盖是必然的。正确做法是带上前置状态的更新条件：update ... set status = 3 where id = xxx and status = 2，更新影响行数为0则说明状态不对，抛出异常。MyBatis Plus的乐观锁插件就是干这个的，本质上就是CAS（比较并交换）思想。

3.4 索引设计原则

这个项目的数据量不会特别大，但索引设计仍然要按规范来做，因为索引设计是一种习惯，做毕业设计时养成的习惯会带到工作里。

主键索引：所有表用id作为单列主键，用bigint类型，AUTO_INCREMENT。雪花算法生成的主键也是bigint，但要考虑是数据库自增还是应用层生成。推荐应用层生成，分布式环境下自增主键会有问题。

唯一索引：appointment_order.order_no建唯一索引，防止并发下生成重复订单号；car_info表建(user_id, plate_no)联合唯一索引，防止同一用户重复绑定同一车牌。

普通索引：appointment_order表的(appoint_date, time_slot_id)联合索引，这是查询最频繁的场景——"某天某时段的订单列表"；(user_id, status)联合索引，支撑"我的订单"列表页；carport表的(zone_id, status)索引，支撑区域+状态的筛选查询。

MySQL索引有个原则：区分度高的列放前面。user_id的区分度远高于status，联合索引时把user_id放前面。建索引不是越多越好，每个索引都会拖慢写入性能，够用即可。

4. 核心业务逻辑实现

4.1 可预约车位的计算逻辑

"某时段还能约几个车位"是整个系统最核心的查询。

可预约数 = 该时段总配额 - 该时段已被预约占用数

这里有个设计要点：总配额不等于车位数。商场停车场在高峰时段不会把所有车位都放给预约，一般预留20%给临时到场车辆，避免预约未到和临时需求造成的资源浪费。这个比例可以在系统配置里动态调整，根据历史爽约率来来优化——爽约率高就调低预约配额，临时需求大就调高预约配额。

具体计算SQL：

SELECT COUNT(*) FROM appointment_order WHERE appoint_date = #{date} AND time_slot_id = #{slotId} AND status IN (1, 2) -- 已支付、已入场

这里查询的是"已占用"的订单数，不包括待支付和已取消的。已支付的才算确定占用，待支付的只占了锁定资源，超时未支付会自动释放，但锁定期内仍然不能放给其他人。

实际项目中不会只查一个时段，车主查询时通常是一个日期加上一天12个时段，一次返回所有时段的余量。循环查询12次数据库的话性能太差，直接一条SQL按时段分组统计：

SELECT time_slot_id, COUNT(*) as booked_count FROM appointment_order WHERE appoint_date = #{date} AND status IN (1, 2) GROUP BY time_slot_id

查询结果放到内存里，和配额做减法就得到每个时段的余量。这个结果同时写入Redis缓存，设60秒过期，再配合一个"某时段余量小于5就预警"的逻辑，运营端就能主动干预。

4.2 预约下单与并发控制

预约下单是这个系统并发压力最大的操作。同一时间大量车主抢同一个时段的车位，就像抢演唱会门票，核心问题是别超卖、别重复。

下单流程设计如下：

1. 参数校验（用户登录态、日期时段合法性、车牌是否已绑定） 2. 检查该时段余量是否 > 0 3. 获取车位级分布式锁 → 锁定一个空闲车位 4. 检查该车位该时段是否已被占用（防重复提交） 5. 插入订单，状态为待支付，锁定期15分钟 6. 释放分布式锁 7. 异步通知用户预约成功待支付

第2步的余量检查只是粗筛，真正的互斥发生在第3步。这里用的Redis分布式锁：

public boolean tryLock(String key, long expireSeconds) { Boolean result = stringRedisTemplate.opsForValue() .setIfAbsent(key, "1", Duration.ofSeconds(expireSeconds)); return Boolean.TRUE.equals(result); }

锁的key是carport:lock:{portId}:{date}:{slotId}，value设为当前线程标识，释放时校验持有者身份，防止误删别人的锁。这个场景锁的粒度是"车位 + 日期 + 时段"，不是全局锁，并发量可以摊到不同车位上。

实际项目里还有一个细节：同一用户同一时段重复预约。用户手抖点了两次提交，第一次成功了第二次还在转圈，于是又点一次。这就需要在业务层做幂等控制。方案是前端生成一个requestId随请求提交，后端查重；同时数据库层面在appointment_order表建(user_id, appoint_date, time_slot_id)的唯一索引，双保险。

4.3 入场与离场流程

预约订单的入场不是一个简单的更新状态操作。车主的入场凭证是二维码，道闸扫码后系统要做这几件事：

校验凭证有效性：二维码内容是一个加密串，解密后得到订单号和车牌号，然后校验订单状态是否为"已支付"、当前时间是否在预约时段内（允许提前15分钟入场）。

支付校验：如果车主预约时勾选了"离场后自动支付"，入场时不用额外操作；如果是"先付预约费、出场时按实际时长补缴"，入场时还要记录入场时间，离场时做结算。

放行后异步更新：道闸放行后，订单状态更新为"已入场"。这步不能做成同步——道闸设备响应时间要求在500毫秒以内，数据库更新如果有网络抖动就很危险。正确做法是扫码校验通过后立刻返回放行指令，同时触发异步任务更新订单状态。

离场流程类似：车牌识别 → 查询订单 → 计算停车时长和费用 → 生成支付单 → 车主支付 → 放行。这里要注意订单和支付单的联动——同一订单只允许存在一笔未支付完成的支付单，支付完成后状态回写订单。

4.4 超时释放机制

预约订单锁定15分钟未支付，系统需要自动释放车位。实现方案有两种，这个项目里我建议组合使用。

方案一：延迟队列。使用RabbitMQ延迟消息，订单创建时发送一条15分钟后的延迟消息，消费者收到后检查订单状态，如果是待支付则自动取消并释放车位。优点是实时性好、触发及时，缺点是引入了消息中间件，架构复杂度上升。

方案二：定时任务扫描。使用Spring的@Scheduled注解，每30秒扫描一次待支付订单，把创建时间超过15分钟且状态仍为待支付的订单批量取消。

我实际用下来推荐方案二，原因有两个：一是这个系统的订单量级远达不到消息队列的需求，二是延迟队列的可靠性配置比较繁琐，而定时任务逻辑直观、排查问题容易。对于一个单体系统，技术方案的第一原则是能简单就不复杂。

定时任务的实现要点是避免重复扫描——用行锁或者状态条件UPDATE防止同一订单被两个线程同时处理：

@Scheduled(fixedDelay = 30000) public void releaseTimeoutOrders() { LocalDateTime deadline = LocalDateTime.now().minusMinutes(15); // 一次性取回所有超时待支付订单ID List<Long> orderIds = orderMapper.selectTimeoutOrders(deadline); for (Long orderId : orderIds) { // CAS更新，只有待支付状态才能变成已取消 int rows = orderMapper.cancelIfWaiting( orderId, OrderStatusEnum.WAITING_PAY.getCode()); if (rows > 0) { // 更新成功后释放车位状态 carportMapper.releasePort(orderId); } } }

5. 实操搭建与关键代码走读

5.1 项目初始化与目录结构

项目用的是标准的Maven多环境配置，开发环境和生产环境分离。初始化关键步骤：

# 使用Spring Initializr生成基础工程 curl https://start.spring.io/starter.zip \ -d dependencies=web,mysql,mybatis-plus,redis,jwt \ -d javaVersion=8 \ -d name=parking-system \ -o parking-system.zip

如果网络不便，也可以在IDEA里直接通过Spring Initializr面板创建，选依赖的时候注意勾选：Spring Web、MySQL Driver、Validation、Redis。

推荐用Spring Initializr然后手工分包，而不是用现成脚手架。团队里用脚手架确实快，但自己做项目学习时，手写Controller、Service、Mapper层的每个文件，能帮你理解分层架构的边界在哪。

分层架构的目录结构：

com.parking.system ├── controller // 接口层，只做参数接收和结果封装 ├── service // 业务层，核心业务逻辑 │ └── impl ├── mapper // 数据访问层，MyBatis Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto // 请求参数对象 ├── vo // 返回视图对象 ├── config // 配置类（Redis、MyBatisPlus、Interceptor） ├── common // 通用工具（统一返回、异常、常量） ├── utils // 工具类（JWT工具、加密工具） └── job // 定时任务

entity和VO必须分开。直接把实体类返回给前端是新手常犯的错误，如果数据库字段调整了，接口返回结构就会变，前端崩溃了你还得半夜爬起来排查。正确的做法是：数据库实体类承载持久化数据，VO承载展示数据，中间用BeanUtils.copyProperties做转换。

5.2 核心业务代码示例

预约下单的Service核心代码，我把关键逻辑完整列出来，你可以直接参考：

@Service public class AppointmentServiceImpl implements AppointmentService { @Resource private AppointmentOrderMapper orderMapper; @Resource private CarportMapper carportMapper; @Resource private RedisTemplate<String, String> redisTemplate; @Override @Transactional(rollbackFor = Exception.class) public AppointmentOrderVO createAppointment(AppointmentCreateDTO dto) { // 1. 校验预约时间是否在可预约范围内（比如只能约未来3天） LocalDate appointDate = dto.getAppointDate(); if (appointDate.isAfter(LocalDate.now().plusDays(3))) { throw new BusinessException("最多只能预约未来3天的车位"); } // 2. 幂等校验：同一用户同一天同时段只允许一单 Long userId = UserContext.getUserId(); Long exists = orderMapper.selectCount( new LambdaQueryWrapper<AppointmentOrder>() .eq(AppointmentOrder::getUserId, userId) .eq(AppointmentOrder::getAppointDate, appointDate) .eq(AppointmentOrder::getTimeSlotId, dto.getTimeSlotId()) .in(AppointmentOrder::getStatus, Arrays.asList(WAITING_PAY.getCode(), PAID.getCode(), ENTERED.getCode()))); if (exists > 0) { throw new BusinessException("您已预约该时段，请勿重复预约"); } // 3. 查询该时段已占用数量 long booked = orderMapper.selectCount( new LambdaQueryWrapper<AppointmentOrder>() .eq(AppointmentOrder::getAppointDate, appointDate) .eq(AppointmentOrder::getTimeSlotId, dto.getTimeSlotId()) .in(AppointmentOrder::getStatus, Arrays.asList(WAITING_PAY.getCode(), PAID.getCode(), ENTERED.getCode()))); TimeSlot slot = timeSlotMapper.selectById(dto.getTimeSlotId()); if (booked >= slot.getQuota()) { throw new BusinessException("该时段车位已约满"); } // 4. 选择一个空闲车位并加锁 String lockKey = "carport:lock:" + dto.getPortId() + ":" + appointDate + ":" + dto.getTimeSlotId(); boolean locked = tryLock(lockKey, 10); if (!locked) { throw new BusinessException("该车位正在被其他用户预约，请稍后重试"); } try { // 5. 二次检查车位状态（防止缓存过期导致的超卖） Carport carport = carportMapper.selectById(dto.getPortId()); if (carport == null || carport.getStatus() != 0) { throw new BusinessException("车位不可用"); } // 6. 生成订单号，创建订单 String orderNo = generateOrderNo(); AppointmentOrder order = new AppointmentOrder(); order.setOrderNo(orderNo); order.setUserId(userId); order.setPlateNo(dto.getPlateNo()); order.setPortId(dto.getPortId()); order.setAppointDate(appointDate); order.setTimeSlotId(dto.getTimeSlotId()); order.setStatus(WAITING_PAY.getCode()); order.setCreateTime(LocalDateTime.now()); order.setExpireTime(LocalDateTime.now().plusMinutes(15)); orderMapper.insert(order); // 7. 更新车位状态为锁定 carportMapper.updateStatus(dto.getPortId(), 1); return convertToVO(order); } finally { releaseLock(lockKey); } } }

有几个技术点需要单独说明。

为什么加@Transactional：创建订单和更新车位状态必须在一个事务里——订单创建成功但车位状态没更新，就会出现"订单存在但车位显示空闲"的数据不一致。rollbackFor = Exception.class表示任何异常都回滚，否则Spring只回滚RuntimeException。

幂等校验的查询条件是WAITING_PAY、PAID、ENTERED三种状态：已取消和已完成的订单不限制重复预约，这样用户取消后可以重新预约。

这里存在一个边界情况：booked >= slot.getQuota()这个判断在分布式场景下并不绝对安全——两个并发请求同时查到的booked都是n-1，都小于quota，都通过了检查。所以真正的互斥靠的是第4步的分布式锁。这个分布式锁的粒度是具体车位，两个请求如果抢的是不同车位，锁不冲突，但都通过了余量检查就可能超卖。解决这个问题有两种思路：如果能定位到具体车位，锁粒度就是"车位"；如果只定位到时段，锁粒度就应该是"时段"，把整个时段的预约操作串行化。实际业务中比较推荐"时段锁 + 车位分配"的二级方案，但为了讲解简洁，示例代码里用的是车位锁。

5.3 接口设计规范与前后端协作

接口设计上有几条约定，对于前后端分离开发尤其重要。

统一返回结构：

{ "code": 200, "message": "success", "data": { } }

code是业务状态码，200成功、400参数错误、401未登录、500系统错误。前端可以根据code统一处理，而不是在每次请求的success回调里写错误分支。

分页参数规范：所有列表接口统一接收pageNum和pageSize，返回时用PageResult对象，包含total、list、pageNum、pageSize四个字段。不要有的接口用page、有的用current，团队协作时这种事特别磨人。

日期时间格式化：后端返回的时间统一用时间戳或yyyy-MM-dd HH:mm:ss格式字符串，前端拿到后用统一的工具类解析，不要每个页面对一个字段单独处理。

错误信息友好化：例如"该时段已约满"这种业务错误，不应该出500，而应该用400或自定义业务码返回，并附带给用户看的提示信息。前端业务层可以根据业务码决定是否弹窗提示。

在这个项目里，前后端协商接口时单子要列清楚，包括每个字段的类型、含义、是否必填、取值范围。这一步做好了，联调时能节省大量反复沟通的时间。我一般的做法是先把所有接口的出入参用表格或在线文档确定下来，再分工开发，联调时基本是改改字段名的小问题，不会出现接口推倒重来的大返工。

6. 常见问题与排查心得

6.1 预约超卖问题

这是做停车预约系统最容易踩的坑，也是面试官最喜欢问的点。

现象：查询余量显示还有3个，但点击提交时提示"车位已约满"。

原因：这是超卖保护的正常表现，不是bug。查询余量的SQL和提交订单的SQL之间存在时间窗口，两个请求并发进入，都看到余量是3，但只有一个能真的下单成功。系统优先保证不超卖，所以后提交的那个请求就会被拒。提示文案改成"手慢了，该时段车位已被约满"会友好很多。

排查方法：如果经常出现余量显示正常但下单失败的情况，先怀疑分布式锁是否有问题。在Redis管理工具里观察carport:lock:*的存活时间和剩余数量，如果锁永久不释放，大概率是释放锁的逻辑没走——常见原因是在finally块之前抛异常，锁根本没执行到finally。解决方式是用try-finally确保释放锁的代码必然执行，同时给锁设置合理的过期时间作为兜底。

性能优化：如果锁竞争太激烈（大量请求抢同一车位），可以考虑在业务层做余量本地缓存，减少对Redis的并发访问。但这个优化做不做，取决于实际的并发量，在没有压测数据之前不要盲目加缓存。

6.2 缓存与数据库的一致性

余量数据在Redis里缓存了，如果数据库更新了但缓存没更新，就会看到不一致的余量数据。

现象：用户A预约成功后，用户B查询余量，结果还是原来的数量。

原因：缓存更新失败。数据库事务提交后，删Redis缓存的操作可能因为网络抖动等原因没有执行成功。这时候缓存里的旧数据会一直存在，直到过期。

解决方案：先更新数据库，再删除缓存，最后在缓存删除失败时通过重试机制兜底。也可以用可靠性更高的"异步双删"策略——删除缓存后，隔一小段时间再次删除。具体到这个项目，我用了更简单的方案：数据库事务提交后，通过Spring的事件机制发布一个"余量变化"事件，监听器负责删除缓存，如果删失败就记录日志，由定时任务补偿。

这里有个反直觉的点要提醒：先删除缓存、再更新数据库，在多线程环境下反而更容易出问题。假设线程A删缓存、线程B查缓存，B发现缓存为空就去查数据库，查到的可能是A还未更新的旧数据，于是把旧数据写回缓存，A的更新就永远被缓存覆盖了。所以常规做法是"先更新库、后删缓存"。

6.3 支付回调的幂等性问题

接入微信或支付宝支付后，支付回调的幂等性处理必须正确。第三方支付的回调通知机制是"多次通知、直到成功"，同一个支付结果可能收到多次通知。

现象：用户支付成功后，订单状态变成了两次更新，一次有值一次覆盖成了空。

原因：回调处理逻辑没有做幂等判断。第一次回调把订单状态改成"已支付"，第二次回调又触发了一遍更新逻辑。

解决方案：在回调处理入口先查订单状态，只有当前状态是"待支付"才做支付成功处理：

public void handlePayCallback(String orderNo) { // 先查订单状态 AppointmentOrder order = orderMapper.selectByOrderNo(orderNo); if (order.getStatus() != OrderStatusEnum.WAITING_PAY.getCode()) { // 状态不是待支付，说明已经处理过了，直接返回 return; } // 使用乐观锁更新，避免并发回调 int rows = orderMapper.updateStatusIfWaiting(orderNo); if (rows > 0) { // 只有更新成功才执行后续逻辑（发短信、更新车位状态等） } }

同时支付流水表要建唯一索引(order_id, pay_type)，即使回调重复处理，插入流水时也会因唯一索引冲突而失败，不会出现重复的支付流水。

6.4 定时任务重复执行

多实例部署时，@Scheduled定时任务会在每个实例上各执行一次，导致超时释放逻辑被重复触发。

现象：同样的超时订单被处理了两次，日志里有两条相同订单的处理记录。

原因：默认的@Scheduled不感知分布式环境，每个应用实例独立调度。单机部署没这个问题，但做成Docker多副本部署后就会出现。

解决方案：最简单的方法是用Redis分布式锁保证同一时间只有一个实例执行定时任务。在任务方法一开始就尝试获取一个全局锁：

@Scheduled(fixedDelay = 30000) public void execute() { String lockKey = "job:releaseTimeoutOrders"; boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(25)); if (!locked) { // 说明其他实例已经在执行了 return; } try { // 执行实际的释放逻辑 } finally { redisTemplate.delete(lockKey); } }

锁的过期时间要稍微大于任务最长执行时间，如果任务30秒能跑完，锁就设25秒过期——万一任务跑挂了，锁25秒后自动消失，其他实例可以继续。这里隐含着一个权衡：锁过期时间设太短，会导致两个实例同时执行；设太长，任务挂掉后恢复的时间就长。我的习惯是任务平均耗时的2到3倍。

7. 几个值得留意的经验沉淀

项目做完了，有几条实际经验我认为比代码本身更有迁移价值。

第一，业务规则要配置化而不是写死。预约的提前天数、取消时限、超时分钟数、分时段配额，这些规则放数据库或者配置文件，运营人员调整规则时不用重启服务。写代码的时候多问自己一句"这个数值以后会不会变"，问完就有答案了。

第二，造数据要早点造。开发阶段尽早把模拟数据造出来，几百个车位、几千条订单，用真实量级的数据量去测。很多性能问题在数据量小的时候根本暴露不出来，等上线了才发现慢SQL就晚了。我当时就吃过这个亏——车位只有20条测试数据时一切秒开，导入500条真实数据后列表页响应从50毫秒变成800毫秒，一查是索引没建对。

第三，异常处理要分层次。业务异常（如"车位已满"）返回友好提示给用户，但不打印堆栈；系统异常（如数据库连接失败）要记录完整堆栈方便排查，同时返回兜底的"系统繁忙"提示。统一用全局异常处理器来做，不要在每个Controller里都写try-catch。

第四，考虑安全问题。密码不要明文存储，用BCrypt加密；接口要做登录鉴权，不能未登录就访问业务数据；车牌号、手机号等敏感信息返回时要做脱敏处理。这些在毕设阶段容易被忽略，但实际商用系统里是安全隐患。

最后再说一个很多人做类似项目时会踩的坑：不要一上来就写代码。先把角色、流程、状态机、数据关系在文档里画清楚，哪怕只是简笔画，代码实现时会顺畅很多。状态机没有提前设计好，写到最后业务逻辑会越写越乱，各种状态分支交织在一起很难维护。这个项目的前期设计花了一周时间，后面写代码只花了半个月，整体效率远高于直接动手写。