SpringBoot+SSM智能停车场管理系统实战：从表设计到部署避坑

1. 项目概述：这套智能停车场管理系统到底做了什么

说句实在话，Java Web方向的实战项目做了这么多年，我最推荐新手和应届生碰的就是“管理系统”这一类，而停车场管理系统又是其中性价比极高的选题。它既有业务复杂度——涉及车辆进出、计费策略、车位状态流转、用户角色权限，又不像电商系统那样动不动就牵扯支付、秒杀、分布式，单机单库就能跑通整个闭环。今天这篇复盘，我以“基于Java+SpringBoot+SSM的智能停车场管理系统”为例，把从需求分析、技术选型、数据库设计到核心代码实现、部署调试的完整链路摊开来讲。

这套系统简单来说解决的是传统停车场管理中的几大痛点：车辆进场登记靠人工、出场计费容易扯皮、车位使用情况不透明、月卡和临时车混在一起难管理。系统通过Web化管理，让管理员在后台完成车位监控、车辆放行、费用计算、订单统计，用户端则可以完成月卡充值、车位查询、停车记录查看。对学习者而言，它覆盖了SpringBoot自动装配、SSM框架整合、MyBatis持久层操作、JWT或Session鉴权、MySQL事务控制、聚合统计报表等Java Web高频考点，可以说是拿一个项目串起了面试八股里半壁江山。

这个项目的定位也很清晰：如果你是正在做毕业设计的学生，或者想从零开始有一个“能跑、能讲、能扩展”的Java后端项目的转行开发者，这套系统的源码结构和业务模式非常值得参考。全文我会尽量还原我实际开发时的思路和踩坑过程，不绕弯子，直接给能落地的方案。

2. 整体设计与技术选型：为什么是SpringBoot+SSM这套组合

2.1 从SSM到SpringBoot：不是替代，而是承上启下

先明确一个概念：题目里写的是“SpringBoot+SSM”，很多初学者看到这两个词会懵，感觉像是两套东西叠在一起。实际上SSM指的是Spring、SpringMVC、MyBatis这三个框架的组合，而SpringBoot本身是基于Spring生态的开发脚手架，它并不会替代SpringMVC或MyBatis，反而是把原本繁琐的XML配置和依赖管理给自动化了。

在传统SSM项目里，你要手动配置web.xml、spring-mvc.xml、spring-mybatis.xml，还要处理一堆jar包版本冲突。SpringBoot最核心的价值就是“自动配置”，它通过starter机制把SpringMVC、默认的Tomcat容器、数据源连接、MyBatis的SqlSessionFactory全部装配好，你只要在application.yml里写少量参数，就能把一个以前要折腾半天的SSM项目跑起来。所以严格说，这套系统的技术栈本质是“SpringBoot作为外壳 + Spring管理Bean + SpringMVC处理Web请求 + MyBatis操作数据库”，也就是SpringBoot化之后的SSM。

这套选型最大的优势是：代码结构和面试点都足够经典。你既可以用它解释清楚Spring的核心机制，比如IoC容器、AOP事务管理，又能拿出来SpringBoot的自动配置原理、启动流程、配置优先级这些进阶问题。相比直接上手微服务、SpringCloud Alibaba那一套，这个项目的复杂度更适合作为个人能力展示的第一个完整闭环，不会让人一看就觉得你是照葫芦画瓢背出来的。

2.2 SpringBoot版本选型的坑：版本太高真的会出事

在热词里我看到“springboot版本太高”这个搜索词，真的很有共鸣，因为这是我在帮别人调试项目时遇到最多的问题之一。很多拿到的源码用的是SpringBoot 2.3.x或者2.7.x，但你自己新建项目时IDEA默认拉取的是SpringBoot 3.x，结果一堆Javax相关的包全部报红，代码根本编不过。

原因在于SpringBoot 3.x把基础包名从javax.迁移到了jakarta.，并且强制要求JDK 17以上。而大部分教学项目、毕设源码用的是JDK 1.8和javax.servlet、javax.validation这一套API。如果你在2.x项目上强行升级到3.x，不是简单改个版本号就能解决的，涉及依赖重写、代码替换、Tomcat容器变化，工作量等同于重构。

我的建议是：做这一类SSM整合项目，优先锁定SpringBoot 2.7.x版本，这是2.x系列的最终维护版本，稳定性和兼容性都最好。数据库连接用MySQL 5.7或8.0，JDK用1.8，Maven用3.6.3以上。这套组合虽然看起来“老”，但恰恰是当前企业里存量项目最常见的配置，面试时候讲出来反而更有说服力。

2.3 系统整体架构：前端页面、后端接口、数据库三层

整套系统的架构设计并不复杂，我习惯把它分成三层来看。

表现层就是浏览器里的管理后台页面，常见做法是Thymeleaf模板引擎直接渲染，或者前后端分离用Vue+Element UI。考虑到这个项目的核心价值在后端逻辑，用Thymeleaf可以少搭一套前端工程，部署时打成单jar包就能跑，很适合毕设演示；如果你有精力，也可以把后端RESTful接口写好，再用Vue单独做个管理界面，这样项目在面试时能多讲一个“前后端分离”的亮点。

后端层就是SpringBoot应用，接收请求后先走Controller层做参数校验，再进Service层处理业务规则，MyBatis的Mapper层负责和数据库交互。业务上主要包含管理员登录鉴权、车位管理、车辆进出场记录、计费规则计算、订单与充值管理、统计数据报表这几个模块。

数据层是MySQL，核心表包括管理员表、用户表（月卡用户）、车位表、车辆表、进出场记录表、计费规则表、订单表。表结构我会在下一节详细给出。

这样一个分层的好处是职责清晰，出了问题能快速定位是前端传参问题、后端逻辑问题还是SQL问题。而且当你以后接触分布式系统时，这种分层思想是通用的，只是把本地Service调用换成RPC或HTTP调用而已。

3. 数据库设计与核心模块拆解：先把地基打牢

3.1 核心数据表结构设计

在写业务代码之前，我花了一晚上把数据库表结构定了下来。好的表设计能让后面的代码轻松一半，尤其像停车场这种涉及状态流转和数据统计的系统，表和表之间的关联关系必须提前理清楚。

我实际用的核心表大概有七张，这里挑关键字段说一下设计思路：

管理员表（admin）

• id：主键，自增
• username：登录账号，唯一索引
• password：加密后的密码，不存明文
• real_name：真实姓名
• create_time：创建时间

用户/车主表（user）

• id、username、password、phone、real_name
• balance：账户余额，月卡车用来扣费
• user_type：用户类型，区分临时用户和月卡用户
• status：状态，是否禁用

车位表（parking_space）

• id、space_no：车位编号，比如A-001
• area：区域
• status：车位状态，0空闲1占用2锁定
• type：车位类型，普通/新能源
• update_time：状态更新时间

车辆表（vehicle）

• id、plate_number：车牌号
• user_id：关联用户表，临时车可以为空
• brand：品牌，选填
• create_time

进出场记录表（entry_exit_record）

• id、plate_number、entry_time、exit_time
• space_id：使用的车位
• status：记录状态，比如“已进场”“已完成”
• fee：应收费用
• real_fee：实收费用
• coupon_id：如果有优惠券可以关联

计费规则表（charging_rule）

• id、rule_name：规则名称，如“临时车首小时5元”
• car_type：适用车辆类型
• free_minutes：免费时长
• unit_price：单位价格
• unit_minutes：计费单位
• cap_amount：单次封顶金额
• is_active：是否启用

订单表（order）

• id、order_no：订单编号，用时间戳加随机数生成
• plate_number、user_id、entry_record_id
• amount：订单金额
• status：支付状态，0未支付1已支付2已退款
• pay_time、create_time

这种表结构的特点是：计费规则单独成表，以后想改停车收费标准，管理员在后台改数据就行，不需要改代码重新部署。这是许多初学项目最容易忽略的点，他们把计费逻辑硬编码在Service里，一旦要调整价格就得改源码，非常不优雅。

3.2 功能模块拆解：一个完整停车流程涉及哪些环节

接下来把系统按业务流程走一遍，你就能直观看到每个模块的作用。

车主开车进场，管理员在系统里选择“车辆入场”，输入车牌号，系统先查这个车牌是不是月卡车：是月卡车，直接放行，记录进场时间，分配一个空闲车位；是临时车，同样记录车牌和进场时间，锁定车位。这里要注意的是，车辆入场动作会同时操作三张表：车辆表、车位表、进出场记录表，而且必须放在同一个事务里，否则可能出现记录进场成功但车位状态没改成占用的情况。

车辆出场时，系统根据车牌查出进场记录，计算出停车时长，再套用计费规则表里的收费标准，生成订单。临时车要先支付订单再抬杆放行，月卡车则直接从余额里扣费，如果余额不够，可以走线上充值再扣。出场后修改车位状态为空闲，写完成记录。

除了进出场这个核心链路，系统还包括管理员对车位的增删改查、对用户的管理和禁用、停车订单的查看与导出、按日/月统计营收和车流量的报表模块。这里每一个模块单独拿出来都不难，但串起来就构成了一套完整的业务闭环。

3.3 状态机思维：车位、订单、记录的状态流转

做管理系统最怕的是状态混乱，比如同一车位被两辆车同时占用，或者订单支付了但记录还是未支付。我的做法是在设计阶段就给每个核心字段画出状态流转路径。

车位只有三个状态：空闲、占用、锁定。初始是空闲，车辆进场后变成占用，出场后回到空闲；锁定是给管理员预留的，比如车位损坏或者被长期占用的特殊车位。订单状态有四个：未支付、已支付、已取消、已退款。车辆出场生成订单后是未支付，支付成功后变为已支付，超过一定时间未支付可以取消，管理员退款后变成已退款。

状态流转路径一旦清晰，写Service的时候就不会出现逻辑漏洞。比如你在“车辆入场”方法里，第一步就要判断车位状态是不是空闲，不是就抛异常；在“车辆出场”方法里，第一步判断记录是不是“已进场”状态，防止重复出场造成二次计费。

4. 核心业务逻辑与代码实现：从登录鉴权到计费算法

4.1 管理员登录鉴权：Session还是JWT？

先聊聊登录鉴权的选择。这个项目我建议用JWT，因为无状态、拓展性好，也符合现在企业里接口鉴权的常见做法。简单说，前端把用户名密码通过POST请求发到后端，后端校验成功后生成一个Token字符串返回给前端，前端后续请求带上这个Token，后端在拦截器里解析Token来确认用户身份。

JWT的核心代码并不复杂，依赖引入jjwt：

java复制<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>

生成Token的工具类：

java复制public class JwtUtil {

    private static final String SECRET = "parking-system-secret";
    private static final long EXPIRE = 1000 * 60 * 60 * 12; // 12小时

    public static String createToken(Integer adminId, String username) {
        JwtBuilder builder = Jwts.builder()
                .setId(String.valueOf(adminId))
                .setSubject(username)
                .setIssuedAt(new Date())
                .signWith(SignatureAlgorithm.HS256, SECRET);
        builder.setExpiration(new Date(System.currentTimeMillis() + EXPIRE));
        return builder.compact();
    }

    public static Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET)
                .parseClaimsJws(token)
                .getBody();
    }
}

实际生产环境里，密钥不能写在代码里，要放到配置中心或环境变量中；过期时间也要根据业务场景调整，管理后台12小时过期算是比较合理的值。

写一个HandlerInterceptor做Token校验：

java复制public class JwtInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (!(handler instanceof HandlerMethod)) {
            return true;
        }
        String token = request.getHeader("Authorization");
        if (token == null || !token.startsWith("Bearer ")) {
            response.setStatus(401);
            return false;
        }
        try {
            Claims claims = JwtUtil.parseToken(token.substring(7));
            request.setAttribute("adminId", Integer.parseInt(claims.getId()));
            request.setAttribute("username", claims.getSubject());
            return true;
        } catch (Exception e) {
            response.setStatus(401);
            return false;
        }
    }
}

在WebMvcConfig里注册拦截器，并放行登录接口：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new JwtInterceptor())
                .addPathPatterns("/api/**")
                .excludePathPatterns("/api/login", "/api/register");
    }
}

为什么选择JWT而不是传统的Session？管理后台如果部署在多台服务器上，Session需要做共享或粘滞会话，而JWT天然支持水平扩展。当然JWT也有缺点，比如服务端无法强制让token失效，这一点在真实项目中通常靠“黑名单”机制或缩短过期时间来解决。

4.2 车辆入场时的核心事务处理

车辆入场是整个系统中事务性最强的一个操作。我直接给出Controller和Service的关键实现，但先强调一下事务注解@Transactional的正确用法。

入场流程需要做这几件事：

1. 判断车牌号是否为空
2. 查询车辆是否存在，不存在则登记新车
3. 分配一个空闲车位
4. 创建进场记录
5. 修改车位状态为占用

Controller层只负责接收参数和返回结果，业务全在Service里。这里有个初学者容易踩的坑：@Transactional要加在Service的public方法上，不能加在不是外部调用入口的private方法上；而且事务方法内部try-catch异常会导致事务失效，因为异常被吞掉后Spring感知不到，无法触发回滚。

车辆入场Service的核心逻辑是这样的（用MyBatis操作数据库）：

java复制@Override
@Transactional(rollbackFor = Exception.class)
public EntryResult vehicleEntry(String plateNumber) {
    // 1. 校验车牌
    if (StringUtils.isBlank(plateNumber)) {
        throw new BusinessException("车牌号不能为空");
    }

    // 2. 查询车辆是否存在，不存在则创建临时车辆
    Vehicle vehicle = vehicleMapper.findByPlateNumber(plateNumber);
    if (vehicle == null) {
        vehicle = new Vehicle();
        vehicle.setPlateNumber(plateNumber);
        vehicle.setCreateTime(LocalDateTime.now());
        vehicleMapper.insert(vehicle);
    }

    // 3. 查找空闲车位
    ParkingSpace space = parkingSpaceMapper.findOneAvailable();
    if (space == null) {
        throw new BusinessException("停车场已满，无空闲车位");
    }

    // 4. 修改车位状态
    parkingSpaceMapper.updateStatus(space.getId(), 1);

    // 5. 创建进场记录
    EntryExitRecord record = new EntryExitRecord();
    record.setPlateNumber(plateNumber);
    record.setEntryTime(LocalDateTime.now());
    record.setSpaceId(space.getId());
    record.setStatus(1); // 已进场
    entryExitRecordMapper.insert(record);

    return new EntryResult(record.getId(), space.getSpaceNo());
}

这里最容易忽略的是并发问题：如果两辆车同时入场，都查到了同一个“空闲车位”，就会出现超卖。单机部署时，最简单可靠的方案是对车位表的更新加条件判断：update status = 1 where id = #{id} and status = 0，如果影响行数为0说明车位已被占用，重新分配或报错。这也是乐观锁的一种简化实现，理解了这个点，你在面试里讲“并发控制”就有真实案例可讲了。

4.3 计费算法的规则化设计：临时车、月卡车、封顶与免费时长

计费是停车场系统的核心，如果写死在代码里，后续调价会让你痛苦到怀疑人生。我的设计思路是把计费规则抽成一张表，每次车辆出场时，根据车牌类型找到对应的规则来计算费用。

先看规则表里的关键字段：free_minutes是免费时长，比如前30分钟免费；unit_price是单价，unit_minutes是计费单位，比如每30分钟收费2元；cap_amount是单次封顶，比如一天最多收30元。

计算逻辑可以这样实现：

java复制public BigDecimal calculateFee(ChargingRule rule, LocalDateTime entryTime, LocalDateTime exitTime) {
    // 1. 计算总停车分钟数，向上取整
    long totalMinutes = Duration.between(entryTime, exitTime).toMinutes();
    if (totalMinutes <= 0) {
        totalMinutes = 1;
    }

    // 2. 判断是否在免费时长内
    if (totalMinutes <= rule.getFreeMinutes()) {
        return BigDecimal.ZERO;
    }

    // 3. 扣除免费时长后，按计费单位计算费用
    long chargedMinutes = totalMinutes - rule.getFreeMinutes();
    long units = (long) Math.ceil(chargedMinutes / (double) rule.getUnitMinutes());
    BigDecimal fee = rule.getUnitPrice().multiply(BigDecimal.valueOf(units));

    // 4. 判断是否超过封顶金额
    if (rule.getCapAmount() != null && fee.compareTo(rule.getCapAmount()) > 0) {
        fee = rule.getCapAmount();
    }

    return fee;
}

这里有两个细节值得注意：

第一，停车时间必须用Duration计算，不要自己算毫秒数差值，可读性差还容易算错单位。而且计费时长通常要向上取整，停1小时01分就算2个计费单位，不能吃亏。

第二，BigDecimal用来计算金额，绝对不能用double。double在二进制下无法精确表示0.1这类十进制小数，累计多了会出现0.30000000000000004这种问题。这两个细节都是面试官爱问的细节。

月卡车的计费逻辑略有不同：车辆出场时不再实时计算费用，而是看月卡是否在有效期内，如果有效就直接放行；如果过期了，就按临时车的标准收费。这里有个小坑，就是月卡用户余额不足时怎么办？我设计的方案是允许欠费出场，但会在用户端标记欠费状态，下次进场时提示充值。

4.4 车辆出场结算：事务与幂等

车辆出场比入场多了一步费用结算，操作上需要格外注意幂等性。

出场流程是：根据车牌查询当前未完成的进场记录，如果找不到就报“该车辆无入场记录”；计算停车费用；生成订单；如果是临时车，标记订单待支付；如果是月卡车，直接从余额扣款并标记订单已支付；释放车位，更新记录状态为完成。

为了防止同一个出场请求被重复提交两次，导致订单重复创建、余额被扣两次，我强烈建议在进出口记录表上加上唯一业务约束。比如利用车牌号+进场时间生成一个唯一索引，或者在下单前先查询是否已有该进场记录对应的订单。还有一种更优雅的做法就是“业务幂等键”，前端生成一个requestId，后端记录这个requestId是否已处理过；但在这个系统的复杂度下，先查后插已经足够了。

5. 系统调试与部署运行：从源码到真正跑起来

5.1 本地环境准备清单

不管你是拿到别人的源码还是自己从零写，首先要把环境统一。我给自己带的学生定的标准配置是：

• JDK 1.8（不要装JDK 17来跑2.x的SpringBoot项目，会遇到javax包不存在的问题）
• Maven 3.6.3以上，并配置国内镜像源，不然拉依赖能等到怀疑人生
• MySQL 5.7或8.0，字符集设置为utf8mb4
• IDEA 2022以上版本，装好Lombok插件
• Navicat或DBeaver作为数据库客户端

这些版本号不是玄学，而是我踩坑后的经验值。比如字符集如果用utf8而不是utf8mb4，存emoji或者生僻字车牌时会报错；用Maven默认中央仓库拉jar包，整个项目构建可能耗时十几分钟。

5.2 首次启动的完整流程

假设你已经拿到了源码，按下面这个顺序走一遍，基本能避免一半的报错：

第一步，把源码解压后用IDEA以Maven项目方式打开，等右下角依赖下载完成。如果进度条卡住不动，去改Maven的settings.xml，加上阿里云镜像。

xml复制<mirror>
    <id>aliyunmaven</id>
    <mirrorOf>central</mirrorOf>
    <name>阿里云公共仓库</name>
    <url>https://maven.aliyun.com/repository/public</url>
</mirror>

第二步，在MySQL里创建数据库，最好名字就叫parking_system，然后把项目里的parking_system.sql导入。用Navicat导入时要注意，先用utf8mb4建库再导入，不要直接在默认库上执行脚本。

第三步，修改application.yml里的数据库连接信息，包括用户名、密码、URL。URL里的serverTimezone建议写成Asia/Shanghai，不然从JDBC读取时间会差8小时。

第四步，启动SpringBoot应用，看到“Started ParkingApplication”说明启动成功。如果启动失败，八成是数据库连接信息不对或者端口被占用，应用默认端口通常是8080，可以在配置里改掉，比如server.port=9090。

第五步，浏览器访问http://localhost:9090，用管理员账号登录。首次登录建议先去“计费规则”页面设置好收费标准，再去“车位管理”里把车位的初始状态初始化一下，这样演示车辆进出场时数据才是完整的。

5.3 打包部署：打jar包还是war包？

本地跑通之后，部署到服务器是另一个常见的诉求。SpringBoot项目我推荐直接用Maven的package命令打成jar包，然后扔到服务器上用java -jar运行。

运行时有一些参数值得注意：

bash复制nohup java -jar parking-system.jar --spring.profiles.active=prod > parking.log 2>&1 &

nohup保证终端关闭后进程还能继续跑，日志输出到parking.log方便排查。如果服务器物理内存小于2G，建议加上JVM参数限制内存使用，比如：

bash复制java -Xms256m -Xmx512m -jar parking-system.jar

不然SpringBoot默认的堆内存设置可能会让云服务器直接内存不足，这就对应了热词里那个“java: outofmemoryerror: insufficient memory”的报错。很多人抱怨打包到Docker里一启动就OOM，其实就是没限制JVM堆内存，宿主机内存被占满了。

5.4 MySQL 8.0驱动变化：com.mysql.jdbc.Driver已过时

很多从旧项目扒下来的源码还在用com.mysql.jdbc.Driver这个驱动类，但MySQL 8.0版本的JDBC驱动里，这个类已经被标记为过时，甚至直接移除了。如果你用的依赖是mysql-connector-java 8.x，必须改成com.mysql.cj.jdbc.Driver。

对应的URL格式也变了，我常用的是：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/parking_system?useSSL=false&useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
    username: root
    password: yourpassword
    driver-class-name: com.mysql.cj.jdbc.Driver

allowPublicKeyRetrieval=true这个参数很多教程没写，但MySQL 8.0默认使用caching_sha2_password认证插件，客户端连接时可能因为拿不到公钥而报错。加上这个参数能省掉很多莫名其妙的连接问题。

6. 常见报错与排查技巧实录

这部分是我最想分享的内容，因为大部分人在部署项目时遇到的坑都出奇的相似。我整理了一份速查表，按频率排序，基本覆盖了热词里提到的那些报错场景。

除了这些数据库和版本问题，还要注意MyBatis的SQL日志。常见的Mapper XML映射失败，都是因为resultType和实体类字段没对上。我的排查技巧是先在application.yml里打开SQL日志输出：

yaml复制mybatis:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这样所有执行的SQL语句都会打印到控制台，问题一眼就能看出来。部署到生产环境时再把这个日志关掉或换成logback，不然日志量会很大。

还有一个容易忽略的点是时间相差8小时的问题。如果你在数据库里看到的entry_time和实际时间差8小时，多半是JDBC连接串里的serverTimezone没设置，或者MySQL服务器时区是UTC。确认serverTimezone=Asia/Shanghai，同时检查MySQL的全局时区设置：

sql复制SELECT @@global.time_zone, @@session.time_zone;

如果还是不对，可以在MySQL里执行set global time_zone = '+8:00'，但这样重启后会失效，最稳妥的办法还是在上层统一用Asia/Shanghai。

7. 从毕设到面试：这个项目如何讲出亮点

很多同学把项目做完就完事了，但我觉得最关键的是“会讲”。同一套系统，有的人答辩时只能说自己写了增删改查，有的人能讲出一套完整的问题分析和设计决策，这中间的差距就是面试官筛选人才的分水岭。

讲这个停车场项目时，我建议按“背景-难点-方案-效果”四步来组织语言。比如主动引出下面几个话题：

第一个话题是并发场景下的车位超卖问题。你可以这样讲：停车场高峰期有多辆车同时入场，如果车位分配不做并发控制，两个请求可能拿到同一个空闲车位。我采用的方式是update语句带status条件判断，配合事务管理，保证了数据一致性。这就是一个非常具体且有深度的并发问题，比背“乐观锁悲观锁”的八股强一百倍。

第二个话题是计费规则的可配置化设计。你可以说：传统做法是把计费标准写在代码里，一旦调价就要改代码重新部署；我的方案是引入计费规则表，把免费时长、单价、计费单位、封顶金额全部配置化，支持临时车和月卡车不同计价模式，运营方在后台就能调整价格。这个话题能体现你的抽象能力和对业务需求的理解。

第三个话题是鉴权方案选型。你可以对比Session和JWT的优缺点，说明为什么在这个场景选择了JWT，以及它带来的安全性问题（比如无法服务端主动失效）如何通过过期时间来解决。这个话题直接关联Java Web的高频面试题。

第四，如果你还想继续扩展，可以聊聊后续的优化方向：对接车牌识别摄像头，让车辆进出场全自动化；引入RabbitMQ处理订单支付的异步通知；用Redis缓存车位状态，提升查询性能；把报表模块做成可视化大屏，用ECharts展示每小时车流量和营收趋势。这些扩展方向不需要真的全部实现，但能展示你的技术视野。

如果你在准备面试，把这个项目的源码结构、关键实现、设计思路、遇到并解决的难点都过一遍，再配合SpringBoot和MyBatis的基础原理，基本上Java后端初级岗位的高频考察点都能覆盖到。记住一句话：项目不重要，重要的是你在项目里展现出的思考过程。

8. 项目可以怎么继续扩展

如果你是想把框架能力再往上提一档，可以在现有项目基础上做几个低成本的扩展。

第一个扩展是引入Redis缓存。当前车位查询每次都要查数据库，在高峰期压力会比较大。你可以把车位状态缓存到Redis里，查询走缓存，更新时同步数据库和缓存。这个改动技术难度不高，但能让你在面试时多讲一个“缓存与数据库一致性”的话题。

第二个扩展是接入消息队列。比如出场结算和支付通知可以通过MQ异步处理，减少接口响应时间，同时让系统架构更像真实的生产系统。用RabbitMQ或RocketMQ都可以，这个项目里引入MQ也不会显得突兀。

第三个扩展是做App或小程序端。目前系统是纯Web管理后台，你可以用uni-app写一个面向车主的微信小程序，实现车位查询、预约、月卡购买、缴费功能，后端接口可以复用现有的，只需要补充一套面向小程序端的鉴权方案。这个扩展一旦做完，整个项目就从“毕业设计管理系统”变成了“有C端入口的完整商业产品”，在简历上的含金量会高很多。

当然，扩展之前一定要先把当前系统的每一行代码都吃透，尤其是事务边界、SQL语句和状态流转逻辑。很多人拿到源码第一件事就是改功能，结果基础没打牢，越改越乱。我最推荐的路线是：先跑起来，再对着代码逐行读，最后再动手扩展。

根据我个人的项目经验，停车场管理系统这类选题之所以经久不衰，就是因为它足够贴近真实业务，又恰好在学习者的能力边界内。你会碰到版本兼容、事务一致性、并发抢占、时间计算这些问题，每一个坑踩过去都是实打实的经验。不要怕绕弯路，一个报错一个报错排查下来，你对SpringBoot和SSM的理解会远远超过看一百篇教程的效果。最后分享一个小技巧：调试这类项目时，一定要先把SQL日志打开，把控制台输出的每一条SQL和实际执行结果结合起来看。数据对了，业务就通了一半。