SpringBoot停车场管理系统：预约锁位、计费规则与实战避坑指南

1. 项目概述：这个停车场管理系统到底在做一件什么事

先聊个现象。每年毕业季，Java方向的毕设题目里，停车场管理系统绝对算得上是“常青树”之一，和图书管理系统、购物商城并称三大俗。但俗归俗，这个题目年年都有人做，年年答辩都能见到，因为它背后的业务逻辑是真的完整：有用户、有车位、有预约、有计时计费、有订单、有支付，麻雀虽小五脏俱全，一套做下来几乎把后端开发的核心知识全串起来了。

我当初选这个题，说白了就是看中它“业务闭环清晰、技术覆盖面广、演示效果好”这三点。你用SpringBoot做一套基于Web的智能停车场管理平台，核心要解决的事情无非这么几件：车主能在手机上（或者网页上）看到停车场还有没有空位，能提前预约车位，进场出场能自动计时，离开的时候能缴费结算。管理员则要能看到停车场整体运营情况、管车位、管费率、查订单。整个系统其实就是一个典型的“高并发预约 + 状态流转 + 计费结算”的业务模型，只是规模被缩小到了毕设可以掌控的程度。

这篇文章我会直接把我自己做这套系统时踩过的坑、设计过的表结构、写过的核心逻辑全部拆开来讲，包括车位预约并发怎么防超卖、计费规则怎么设计才能不被老师问倒、SpringBoot版本和JDK版本不匹配导致的编译报错怎么解决、答辩时怎么演示才能拿高分。内容会偏实操，你拿到手之后照着改改就能用。

先说一下这篇博文适合谁看。第一类就是正在选题或者正在写代码的计算机专业学生，尤其以Java方向为主，你可以把这篇当成一份开发前的“踩坑地图”；第二类是想快速搭一个停车场管理系统参考的初级开发人员，这套项目的代码结构比较经典，拿来练手或者改造成商业项目都有空间；第三类是准备做SpringBoot面试项目的同学，这个系统的预约锁位、订单状态机、金额计算这几块，都是面试官比较爱抠细节的点，你理解透了之后，项目经历这一块能聊得很深。

2. 技术选型思路：别一上来就追最新版SpringBoot

先解决一个很现实的问题：SpringBoot到底选哪个版本，JDK到底用哪个版本，这事能劝退一半的人。

很多时候新手拿到题目，看到SpringBoot官网最新的3.x版本，二话不说就往下拉依赖了，结果项目一创建，Lombok报错、JDK版本不对、Servlet API不兼容、MyBatis-Plus还没适配……硬生生被环境问题卡了两三天，代码一行没写。所以在项目启动之前，选型一定要稳。

2.1 SpringBoot、JDK和数据库的版本搭配

我当时的搭配是这样的，这套组合兼容性很稳，网上资料也多，遇到问题基本一搜就能解决：

这里重点解释一下为什么不要一上来就追SpringBoot 3.x。SpringBoot 3.0之后强制要求JDK 17及以上，而很多学校的上机环境、老师电脑里装的是JDK 8，到了答辩演示现场，机器环境不对直接跑不起来，那不是自己给自己挖坑吗？另外SpringBoot 3.x里面有些API做了大调整，比如javax包变成了jakarta包，很多老教程里的代码直接复制过来编译不过。你做毕设的诉求是“稳、快、能跑、好讲”，而不是“帮SpringBoot团队当小白鼠测新版本”，所以老老实实选SpringBoot 2.7.x + JDK 8这一套，是无数人验证过的稳妥方案。

2.2 为什么选MyBatis-Plus而不是JPA

我知道很多老师上课教的是Spring Data JPA，因为Spring官方文档里示例全是JPA，看起来省事。但到了做系统这种场景，我建议你选MyBatis-Plus，理由有三个：

一是SQL可控。车位预约、报表统计这种业务，经常要写相对复杂的查询（联表、分组、条件统计），JPA虽然也能写，但遇到复杂查询时要么推导JPQL、要么写原生SQL，调试起来反而不如MyBatis-Plus直接写SQL灵活。

二是上手成本低。MyBatis-Plus的BaseMapper封装了单表CRUD，你连SQL都不用写就能完成大部分操作，对毕设这种需要快速出活的项目来说太友好了。

三是有坑可循。MyBatis-Plus在国内有海量中文资料，几乎你遇到的每个报错都能在网上找到答案。这一点对新手来说太重要了，你总不想卡在一个注解用法上三天吧。

2.3 前端方案：自研Vue还是模板渲染

前端方案分两派。一派是前后端分离：Vue 2 + Element UI + Axios，后端纯做接口，这样看起来技术栈更“高级”，答辩时能讲的东西更多，但工作量也大，你得同时维护前端工程和后端工程，部署的时候还要解决跨域问题。另一派是服务端渲染：用Thymeleaf模板引擎，页面直接在后端渲染，一套工程打包就能跑，部署简单，答辩演示不容易翻车。

如果你离提交时间还有一个月以上，并且对Vue有一定的熟悉程度，我建议你做前后端分离，因为“SpringBoot + Vue前后端分离”这个组合在简历上、答辩PPT里都更有分量。如果时间只剩两周，我建议直接Thymeleaf，把精力全部集中在后端业务逻辑上，不要让前端拖垮进度。我本人当时是选择了前后端分离，但说实话后期的跨域配置、路由拦截、打包部署确实多花了不少时间，你们可以自己权衡。

3. 整体架构设计：模块怎么划分才不会被老师追问

系统架构这一块，老师答辩时一定会让你画一个系统功能模块图，然后问你“你这个系统的核心业务流程是怎样的”。如果这里你支支吾吾说不太清楚，那你代码写得再好也会被打折扣。所以架构设计不只是写代码前的规划，它本身也是答辩得分的一部分。

3.1 角色权限模型

停车场管理系统里面有两个核心角色：管理员和普通用户。有多余精力的话，你还可以加一个“停车场岗亭管理员”角色，专门负责进出场确认操作。我就按两个角色的基础版来拆。

• 管理员：管理车位（增删改查车位信息）、设置计费规则、查看订单流水、查看运营统计报表、审核用户（如果不做自动注册）。
• 普通用户：注册登录、查看车位空闲状态、预约车位、取消预约、入场（生成停车记录）、出场缴费、查看个人历史订单。

权限这块，基础模式用JWT（JSON Web Token）就够了，不需要引入Spring Security那一套复杂的过滤器链。JWT登录认证的思路是：用户登录成功后，后端生成一个带用户ID和角色信息的Token返回给前端，前端后续请求在Header里带上这个Token，后端用一个拦截器解析Token并放行。对毕设来说，能解释清楚JWT认证流程，已经算亮点。

3.2 后端分层结构

我推荐的分层结构是标准的Controller-Service-Mapper三层，加上一些辅助包：

code复制com.parking
├── controller       // 控制层，接收请求，参数校验
├── service          // 业务层，核心逻辑都在这
│   └── impl
├── mapper           // 数据访问层，MyBatis-Plus接口
├── entity           // 数据库实体类
├── dto              // 前端传入对象，用于参数接收和校验
├── vo               // 返回给前端的数据对象
├── config           // 配置类：拦截器、跨域、JWT工具
├── common           // 统一响应结果、异常处理、工具类
└── ParkingApplication.java  // 启动类

这个结构你闭着眼都能背下来，因为所有Java毕设项目长得都差不多，但它的好处是：模块职责清晰，万一某个类出了问题，你能迅速定位到是哪一层的问题。答辩的时候老师问“你项目结构怎么设计的”，你按这个分层讲，基本不会扣分。

有一点必须提醒：不要在Controller里写业务逻辑。我见过好多同学的代码，Controller里直接new对象、查数据库、算金额，Service层全是空的。这样写虽然也能跑，但答辩时老师翻代码看到这种写法会直接给差评，因为这不是一个合格开发者的习惯。

3.3 统一响应体与全局异常处理

这是个特别加分的细节。很多新手项目接口返回的数据五花八门：有的返回Map，有的返回String，有的直接返回实体类，前端拿到数据还得猜结构。我建议你提前定义一个统一的响应体类，比如：

java复制public class Result<T> {
    private Integer code;      // 200成功，500失败
    private String message;    // 提示信息
    private T data;            // 数据
    // 提供静态方法 success()、error()
}

所有Controller方法统一返回Result类型，前端拿到之后先看code再取data，处理逻辑完全一致。同时配合一个全局异常处理器，用@RestControllerAdvice捕获业务异常和系统异常，统一封装成错误响应。这样不仅代码整洁，而且答辩时你可以指着这个类说“我做了统一异常规范”，老师会觉得你工程化意识不错。

4. 数据库设计：核心表结构和字段设计，照着建就能用

数据库设计是停车场管理系统的灵魂，我见过有人用两三张表硬撑一个停车系统的，答辩时老师问“那用户怎么和订单关联？优惠活动放哪？”，直接答不上来。这套系统的表设计是有规律的，核心思路是“用户—车位—预约—停车记录—订单—费率”的六表模型。

4.1 核心表结构概览

用这个模型，整个业务闭环就能跑通：用户先注册登录，然后查车位，对空闲车位发起预约，预约成功生成预约记录；用户到场后“入场”，预约状态变为已入场，同时插入一条停车记录；出场的时候系统根据fee_rule计算费用，生成订单，用户支付后订单状态变已支付，停车记录状态关闭。

4.2 车位状态字段：为什么需要version

这里我要重点说两个容易踩坑的设计细节。

第一个是车位状态字段。很多人的第一版设计里，车位只有0和1两个状态（0空闲、1占用），但一旦引入预约功能，你就发现不够用了：车位被预约但是人还没到场，车场实际还能不能让别的车停？所以车位状态我建议至少设计三个值：0空闲、1预约占位、2占用中。这样查询空闲车位的时候，只查status为0的即可，预约占位和占用中的车位不在可预约列表里。

第二个是并发控制。想象这么个场景：停车位还剩最后一个，两个用户同时点击“预约”，如果代码逻辑是“select查询车位状态，发现空闲，update状态为预约”，那在极端并发下可能两个请求都查到了空闲状态，然后都执行update，最终这个车位被预约了两次，这就是“超卖”问题。解决的经典方案是在表里加一个version字段，用乐观锁控制更新：

sql复制UPDATE parking_space SET status = 1, version = version + 1 
WHERE id = #{spaceId} AND status = 0 AND version = #{oldVersion}

这个SQL的意思是：只有当我查询时的版本号和当前数据库里的版本号一致，才允许更新成功；如果不一致，说明被别人改过了，更新会返回0行，代码里判断更新条数为0就提示“手慢了，车位已被预约”。这是MyBatis-Plus里@Version注解的底层原理，也是面试常考的点，你把这个讲清楚，绝对加分。

4.3 计费规则表为什么单独建

新手很容易犯的一个错误是：把计费单价写死在代码里，比如每小时5块钱就写一个常量。这样开发省事，但业务上一旦要调整费率，你就得改代码重新部署，明显不合理。单独建一张fee_rule表的优势是：费率配置数据化，管理员在管理后台改数据库或者做一个配置页面，系统立刻生效。

计费规则我要提醒一个字段：daily_cap，也就是每日封顶金额。停车场行业里几乎没有“无限累加”的计费模式，大部分停车场都设有封顶价。你的计费逻辑里如果没有封顶判断，答辩时老师随口一问“停一整天多少钱”，你算出来一个夸张的数字，就会显得业务考虑不周全。还有一个字段free_minutes，表示免费时长，比如进场15分钟内免费，这也是很常见的业务规则，最好也做成可配置。

4.4 订单号的生成

订单表里order_no字段，别用自增ID，因为实际项目里订单号有自己的格式规范。我当时用的生成规则是“时间戳 + 随机数”，具体来说就是yyyyMMddHHmmss加上6位随机数，再拼接一个用户ID后四位，保证唯一性。如果你想把逼格拉高一点，可以研究一下雪花算法（Snowflake），它生成的ID是趋势递增的Long类型，全局唯一而且性能高，面试也可以讲。毕设阶段用“日期时间+随机数”完全够用，但注意给order_no加唯一索引，防止并发情况下随机数撞了。

5. 核心功能实现细节：预约、计费、缴费的关键逻辑

数据库设计完之后，就到了写代码的环节。这一部分我不贴完整代码（太长了），只把核心逻辑的“思考过程”和关键代码片段讲透。你自己写的时候照着这个思路来，就不会跑偏。

5.1 车位预约：事务和锁缺一不可

预约接口是整个系统的“门面”，也是逻辑最重的一块。它的完整流程是：

1. 前端提交预约请求，参数包含车位ID、用户ID、预计入场时间。
2. 后端先校验用户是否登录，再校验车位是否存在。
3. 对车位进行“乐观锁更新”，把status从0改成1，如果更新失败返回“车位已被抢”。
4. 锁位成功之后，插入预约记录（reservation表），状态为待入场。
5. 设置预约过期时间，比如预约30分钟内不入场自动取消。

这个流程里最容易被忽略的是“如果第4步插入预约记录失败，第3步的车位已经被改成预约状态了怎么办”。解决办法是给整个方法加上@Transactional事务注解，任何一步抛异常，数据库自动回滚，车位状态恢复成空闲。

java复制@Transactional(rollbackFor = Exception.class)
public Result<Void> reserve(ReserveDTO dto) {
    // 1. 校验
    ParkingSpace space = spaceMapper.selectById(dto.getSpaceId());
    if (space == null || space.getStatus() != 0) {
        return Result.error("车位不存在或已被占用");
    }
    // 2. 乐观锁更新
    int rows = spaceMapper.lockSpace(space.getId(), space.getVersion());
    if (rows == 0) {
        return Result.error("车位刚被预约了，手慢无");
    }
    // 3. 生成预约记录
    Reservation reservation = new Reservation();
    reservation.setUserId(dto.getUserId());
    reservation.setSpaceId(dto.getSpaceId());
    reservation.setReserveTime(new Date());
    reservation.setExpireTime(DateUtil.addMinutes(new Date(), 30));
    reservation.setStatus(0);
    reservationMapper.insert(reservation);
    return Result.success();
}

这里还有一个小细节：预约过期自动取消。你可以用一个定时任务，每1分钟扫一次预约表，把“超过过期时间且状态还是待入场”的记录，状态改成已过期，同时把对应的车位状态改回空闲。SpringBoot里用@Scheduled注解就能实现，这是除了增删改查之外一个很好的加分功能点。

5.2 计时计费：金额计算的分层策略

计费逻辑看似简单，做起来坑很多。先说基础算法：费用 = 停车时长（小时） × 每小时的单价，但边界情况特别多。比如停车37分钟算多少钱？跨度了2个小时还是按1小时算？比如停了3小时2分钟，很多停车场是“超过1分钟按1小时算”，但也有按分钟计费的。这些规则最好做成可配置的，不要写死在代码里。

我当时设计的计费流程是这样的：

1. 出场时，后端根据停车记录的entry_time算出实际停车分钟数。
2. 如果停车时长小于等于free_minutes（比如15分钟），金额为0。
3. 如果按时段收费：把分钟数转换成小时数，不满1小时按1小时算（向上取整），乘以unit_price。
4. 如果按分钟收费：分钟数直接乘以每分钟单价（unit_price这里存的是每分钟价格）。
5. 如果计算出来的金额大于daily_cap，取daily_cap。
6. 如果有优惠，叠加优惠后再返回前端。

向上取整在Java里可以用Math.ceil方法，但要注意单位换算成double后会有精度问题，金额计算一定要用BigDecimal，别用double和float。这是一个特别基础的财会问题，但很多人初学时就吃了这个亏，算出来9.999999这种数，前端页面显示9.999999难看得一匹。

java复制public BigDecimal calcAmount(ParkingRecord record, FeeRule rule) {
    long minutes = (record.getExitTime().getTime() - record.getEntryTime().getTime()) / 60000;
    if (minutes <= rule.getFreeMinutes()) {
        return BigDecimal.ZERO;
    }
    BigDecimal amount;
    if ("hour".equals(rule.getChargeType())) {
        double hours = Math.ceil(minutes / 60.0);
        amount = BigDecimal.valueOf(hours).multiply(rule.getUnitPrice());
    } else {
        amount = BigDecimal.valueOf(minutes).multiply(rule.getUnitPrice());
    }
    // 封顶判断
    if (amount.compareTo(rule.getDailyCap()) > 0) {
        amount = rule.getDailyCap();
    }
    return amount.setScale(2, RoundingMode.HALF_UP);
}

5.3 缴费：可以用“模拟支付”，但逻辑要闭环

大学生做毕设没有企业支付牌照，也没法真正接入微信支付、支付宝支付，所以大多数人是做一个“模拟支付”页面：用户看到订单金额，点击“确认支付”，就算支付成功。这个思路完全没毛病，但你要注意把支付状态流转做完整。

我推荐的订单状态模型是：

• 待支付（0）：出场时生成订单，用户还没付钱。
• 已支付（1）：用户点击支付，后端模拟支付成功，更新订单状态。
• 已关闭（2）：用户超时未支付，系统自动取消订单（通常配合定时任务）。

支付接口的核心逻辑是：

1. 根据订单号查询订单，检查状态是否是待支付，如果不是直接报错“订单状态异常”。
2. 如果待支付，更新订单pay_status为1，写入pay_time。
3. 更新对应的停车记录状态为“已完成”。
4. 释放车位：把车位status改成0。

这里有个“先更新谁”的顺序问题，我的建议是：先更新订单为已支付，再释放车位，最后关闭停车记录。因为释放车位是核心资源操作，如果前面步骤失败了，车位还被占用着，会导致后续停车被堵死。把车位释放放在最后一步，配合事务回滚，可以尽量避免数据不一致。

5.4 管理后台的统计报表

如果你的系统只做了增删改查，没有报表页面，那这个毕设的“技术天花板”就太低了。建议至少做一个简单的统计页面，用ECharts展示停车场的核心数据：近7天停车量柱状图、每日营收折线图、车位利用率环形图。这些数据的SQL编写思路是：按日期分组查询停车记录，统计当天的记录数和订单金额总和。

sql复制SELECT DATE(entry_time) AS day, COUNT(*) AS total_count, 
       COALESCE(SUM(amount), 0) AS total_amount
FROM parking_record
WHERE entry_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY DATE(entry_time)
ORDER BY day;

统计功能本身不复杂，但它能证明你具备“数据分析思维”，答辩的时候能让老师觉得你做的不只是一个CRUD系统，这是很大的加分项。

6. 开发中的高频问题与排查实录（持续更新）

这一节聊点实在的，都是我在开发过程中实际遇到的问题，也是网上大家问得最多的问题。我按类别整理成速查表，你对照着排查就行。

6.1 环境与编译类问题

6.2 运行期与业务逻辑问题

6.3 几个我特别想强调的坑

第一个坑：不要在实体类里用“驼峰”和“下划线”混着来。MyBatis-Plus默认开启了驼峰映射（map-underscore-to-camel-case=true），所以数据库字段用下划线命名（create_time），实体类属性用驼峰命名（createTime），这会自动映射。如果两者不一致，你会查出null字段，那才是真的排查半天。

第二个坑：金额字段必须精确。数据库用DECIMAL(10,2)，Java用BigDecimal。别图省事用double，也别在数据库用float。这个坑我在第一次测试计费时就踩了：停车时长算出来4.9999999小时，金额直接飞了。

第三个坑：前后端分离部署时，前端打包后的静态文件要扔到后端resources/static目录下，还是单独部署？如果答辩现场网络环境不稳定，建议直接把前端打包好放进后端工程，生成一个fat jar，一条命令跑起来。这样不用再单独起一个前端服务，演示时少一个故障点。

7. 关于密码安全和JWT认证的那点事

用户名密码存储这块，我看很多毕设代码直接明文存在数据库，虽然能跑，答辩时老师不一定问，但一旦问了就会很尴尬。安全这个东西，你可以不做得很深，但至少要有“加盐哈希”的意识。

简单来说就是：用户注册时，不存原始密码，而是对密码加一个随机盐值（salt），然后拼接起来做SHA-256或者BCrypt哈希，把盐和哈希值分开存。用户登录时，用输入的密码加上之前存的盐重新哈希，和库里存的哈希比对。加盐的目的是防止两个用户密码一样时哈希值也一样，反向猜到原始密码。这个逻辑Java实现并不难，网上工具类很多，实在不想自己写，可以引入Spring Security的BCryptPasswordEncoder，它也支持SpringBoot 2.x。

JWT认证的逻辑也不复杂。我的实现思路是：

1. 用一个JwtUtil工具类生成Token，Token里放userId和role，密钥用固定的字符串（毕设够用）。
2. 前端登录后把Token存localStorage，每次请求在Header里带Authorization: Bearer token。
3. 后端定义一个拦截器，拦截除了登录注册以外的所有接口，解析Token确认身份，顺便把userId塞进request的attribute里，方便Controller直接拿。
4. 如果Token过期或解析失败，拦截器直接返回401。

这里要注意，Token要注意设置过期时间，比如24小时。虽然JWT理论上无状态，但毕设里你可以不做刷新逻辑，过期了让用户重新登录就行，不用整太复杂。

8. 答辩演示怎么讲才能拿高分

代码写完只是第一步，很多同学代码写得挺好，但答辩的时候10分钟讲得稀碎，老师一头雾水，分数自然不高。这里分享几个我总结的演示思路。

8.1 先讲架构，再跑流程

PPT或者现场演示的节奏应该是：先花2分钟介绍系统整体功能（用户端+管理端），再用1分钟画出核心流程图（用户预约停车的完整链路），然后才开始演示功能。千万不要一上来就打开系统开始点菜单，老师不知道你要干嘛，也不知道你系统有什么料，看得一头雾水。

8.2 准备一个“演示脚本”

我强烈建议你提前写一份演示脚本，严格按照脚本操作系统，不要临场乱点。脚本可以大概这样写：

1. 管理员登录，进入车位管理，新增一个车位（演示增删改查）。
2. 切换普通用户注册账号，登录。
3. 查询空闲车位，选择预约，展示预约成功页面。
4. 模拟入场，展示车位状态从未分配变已占用。
5. 模拟离场，展示计费金额弹出，点击支付，展示订单列表和状态变化。
6. 切回管理员端，展示今日订单统计和图表。

这个流程完整跑完大约6分钟，把核心功能全部覆盖。关键是过程中的状态变化一定要指着页面给老师看：你看，车位状态从空闲变成预约了，这说明我的锁位逻辑生效了。

8.3 把数据库打开放在旁边

一个很实用的操作是：演示的时候把Navicat或者命令行MySQL打开放在屏幕另一侧。每执行一个操作，你就切到数据库看一眼对应表的数据变化。比如预约成功后切到reservation表看新插入的记录，支付成功后切到orders表看status字段变成了1。这样做的好处是，让老师直观看到你的系统不是“前端糊弄”，而是真的在操作数据库。这一步能立竿见影增加项目可信度。

8.4 准备一个“亮点清单”

答辩前把项目的技术亮点列成清单，等老师问“你这个项目有什么亮点”时，你可以从容输出。我当时准备的清单大概是这样：

• 车位预约采用乐观锁防止并发超卖。
• 计费规则可配置化，支持按时/按次计费，支持免费时长和每日封顶。
• 使用统一响应体和全局异常处理器，接口规范统一。
• 预约过期定时任务自动释放车位资源。
• JWT登录认证实现了无状态鉴权。

不要每个点都展开讲，捡两三个点讲透就行，讲多了老师会追问细节，答不上来反而减分。

9. 写在最后的几个扩展思路

如果你做完基础版本还有余力，想给自己的毕设增加一点区分度，这几个方向成功率比较高。

第一个方向是引入Redis。把“空闲车位列表”缓存起来，查询的时候先查Redis，没有缓存再查数据库，预约成功后及时更新缓存。这个功能点能引出Redis缓存穿透、缓存一致性等话题，面试或答辩都很能打。第二个方向是增加一个“预约入场超时自动取消”的定时任务，这个我们前面说过，实现简单但业务价值明显。第三个方向是做一个简单的微信小程序端，虽然工作量不小，但“SpringBoot + 微信小程序”的组合在毕设里属于降维打击。

我个人实际操作下来的体会是：这套停车场管理系统，技术上并不存在真正的难点，难点在于你要把“场景”和“代码”一一对应起来。同样是SpringBoot的后端代码，为什么有的人做出来像一个玩具，有的人做出来像能上线的产品？差别就在于你对业务细节的理解和对异常情况的处理。你在预约、计费、支付这几条核心链路上多想一步，多做一层校验，你的系统就在同学中脱颖而出了。

最后再分享一个小技巧：写项目的时候，记得把每一个“我当时为什么会这么设计”的记录写下来，放到自己的笔记里。等答辩前看一遍，你会发现自己对项目的理解比想象中深得多，讲起来也会更有底气。祝所有选这个题的同学，一把过。