1. 项目概述与选题思考
1.1 这项目到底解决什么问题
做毕业设计或者接私活时，停车场管理系统是个绕不开的经典选题。我最早接触这类项目，是帮一位学弟梳理毕设思路，当时他拿来的需求描述只有一句话：“做一个能管理车辆进出的系统”。但等到真正上手，才发现这里面牵扯的门道比你想象的多得多——车牌识别要不要做、车位状态怎么实时维护、收费规则怎么灵活配置、月卡用户和临时用户怎么区分对待。
这一次的项目标题是“基于SpringBoot框架的智能车库运营平台设计与实现”，加了个“智慧停车服务系统”的副标题，再往下还有“采用SpringBoot技术的车辆停放信息化解决方案”。说白了，这就是典型的SpringBoot单体应用，做一套覆盖车辆入场、车位分配、费用计算、出场结算全流程的停车管理平台。
这个系统能做什么，拆开看其实非常清楚：
- 车辆入场登记，记录车牌号、入场时间、入场通道
- 车位状态管理，区分空闲、占用、预约状态
- 收费规则配置，支持按时计费、按次计费、免费时段、封顶价格
- 车辆出场结算，自动计算停车时长和费用
- 月租用户管理，支持固定车位和包月套餐
- 数据统计分析，展示车流量、车位利用率、营收报表
对于计算机专业的毕设来说，这个选题的优势极其突出：业务场景真实、技术栈主流、可展示的功能点多、答辩时好讲故事。对于刚学完SpringBoot但缺少完整项目经验的同学来说，也是一个很好的练手项目，能让你把SSM或SpringBoot + MyBatis Plus + MySQL这套组合彻底跑通。
1.2 为什么选SpringBoot做主框架
我见过很多毕设选题，有的用SSH（Struts2 + Spring + Hibernate），有的用SSM（Spring + SpringMVC + MyBatis），还有的直接用Servlet写。不能说这些方案不行，但放在今天的环境下，SpringBoot确实是更合理的选择。
原因很简单：SpringBoot把配置简化到了一个近乎极致的地步。以前搭SSM框架，光XML配置文件就要写好几个，数据源配置、事务配置、MyBatis配置、SpringMVC配置，一不小心就报错，而且报错信息还不直观。SpringBoot用自动配置机制，引入对应的starter依赖，大部分配置都给你准备好了，你只需要关心业务代码本身。
还有一点很实际：现在企业招聘、外包接单、开源社区的讨论主流，都已经全面转向SpringBoot和SpringCloud这套生态。用SpringBoot做毕设，技术栈拿出去是能打的。答辩时老师问你“为什么选这个框架”，你能说出自动配置、内嵌Tomcat、Starter机制、Actuator监控这些点，印象分直接拉满。
停车场的业务场景是典型的CRUD + 状态流转 + 规则计算，SpringBoot处理这类场景非常顺手。它不像微服务那样引入额外的分布式复杂度，也不像纯Servlet那样一切都要手写，是一个“恰好够用”的选择。
1.3 这个项目的目标用户和应用场景
技术上来讲，SpringBoot停车场管理系统有几个明显的受众和应用方向：
毕设学生群体。这是最庞大的用户群。一个功能完整、代码规范、文档齐全的停车场系统，可以直接作为毕业设计论文的支撑材料。论文里写需求分析、功能设计、数据库设计、系统实现、系统测试，每一章都有实际内容可写，不会出现“纸上谈兵”的情况。
中小型停车场运营方。很多路边停车场、小区地下车库、写字楼配套停车场，管理方式还停留在人工登记、纸质票据的阶段。这类场所的信息化需求非常刚性，而SpringBoot单体应用恰好能满足：部署简单，一台普通服务器就能跑，维护成本低，不需要专门的技术团队。
软件开发学习者。如果你正在学习SpringBoot，想找一个有代表性的综合案例练手，停车场系统是很好的选择。它涉及用户认证、权限管理、复杂业务规则、报表统计、前后端交互，几乎覆盖了企业级Web应用的所有常见技术点。
我见过一个比较典型的部署场景：某公司园区内部停车场，高峰期有近三百辆车进出，之前靠保安手写车牌和入场时间，出场时翻本子结算，经常出现纠纷。后来用这套系统接入了简单的摄像头识别服务，入场时自动识别车牌，出场时系统自动计算费用，保安只需要确认收费即可。这就是SpringBoot停车场系统的真实应用价值。
2. 系统功能架构与数据库设计
2.1 核心功能模块划分
从功能层面看，一个完整的SpringBoot停车场管理系统，至少要包含以下几个模块。
用户管理模块：系统管理员、停车场管理员、普通操作员三级角色划分。管理员负责系统配置和全局数据查看，操作员负责日常的车辆进出登记和收费操作。用户表还要支持月租车主信息管理，和场内车位做绑定。
车位管理模块：维护车位的基础信息，包括车位编号、所属区域、车位类型（普通/充电/无障碍）、当前状态（空闲/占用/锁定）。这个模块是停车场系统的地基，所有业务流程都围绕车位状态展开。
车辆进出管理模块：入场时记录车牌号、车辆类型、入场时间、入场通道、分配车位；出场时记录出场时间、停车时长、应收费用、实收费用。这块是整个系统的核心业务，也是代码量最大、最容易出Bug的地方。
收费管理模块：支持多种计费策略的灵活配置。比如按时段计费、按小时阶梯计费、单日封顶、免费停车时长、会员折扣等。费用计算逻辑必须独立封装，方便后续调整规则和扩展新策略。
月租管理模块：管理月租车主的套餐信息、有效期、绑定车位。月租车出场时不再按小时计费，而是校验有效期是否在有效范围内。
统计报表模块：按日/周/月维度统计进出车辆数、平均停车时长、车位周转率、收入明细。这些数据用ECharts在前端展示成图表，视觉效果很好，答辩时加分明显。
2.2 数据库表设计思路
数据库设计是SpringBoot项目的重头戏，表结构的好坏直接决定了后期开发的效率。停车场项目我建议至少设计以下核心表：
- 用户表（sys_user）：账号、密码（BCrypt加密存储）、角色、手机号、状态
- 角色表（sys_role）：角色名称、角色编码、权限标识
- 车位表（parking_space）：车位编号、区域ID、车位类型、状态、备注
- 车辆信息表（vehicle_info）：车牌号、车主姓名、联系电话、车辆类型、是否为月租车
- 入场记录表（entry_record）：记录ID、车牌号、车位ID、入场时间、入场通道、操作人员
- 出场记录表（exit_record）：记录ID、车牌号、入场记录ID、出场时间、停车时长、应收金额、实收金额、支付方式
- 收费规则表（charge_rule）：规则名称、计费方式、单价、免费时长、封顶金额、生效时间
- 月租套餐表（monthly_card）：套餐名称、有效期、价格、关联车位ID
这里我特别提醒一点：入场记录和出场记录不要合在一张表里。因为存在“只入场未出场”的车辆，如果合并成一张表，出场信息为空时查起来很别扭，而且统计多日数据时要反复聚合。拆成两张表，关联字段用入场记录ID连接，逻辑清晰，查询效率更高。
车位表和入场记录表的关系也值得注意。一个车位在同一时间段只能被一辆车占用，所以入场时就要锁定车位状态，出场时释放车位状态。并发场景下可能出现“同一车位同时被分配两次”的情况，解决方案是在更新车位状态的SQL上加上条件判断：
UPDATE parking_space SET status = 1 WHERE id = #{spaceId} AND status = 0这样即使两个请求同时到来，也只有一个能成功更新，另一个受影响行数为0，再提示“车位已被占用”即可。
2.3 业务状态流转设计
停车场系统的核心状态就两个：车位状态和车辆在场状态。但把它们串起来，就形成了完整的业务闭环。
车位有四种状态：空闲（0）、占用（1）、预约（2）、停用（3）。入场时从空闲变为占用，出场时从占用变为空闲。
车辆在场状态则是通过“是否存在未结算的入场记录”来判断的。一辆车入场后，entry_record表里增加一条记录；出场结算后，exit_record表里增加一条对应记录。要判断车辆是否在场，直接查入场记录表中是否存在出场记录ID为空的记录即可。
这个设计有个明显好处：数据可追溯。即使车辆已经出场很久，你依然可以通过入场记录和出场记录的关联，还原当时完整的停车信息，方便后续对账和处理纠纷。
3. 技术栈选型与项目环境搭建
3.1 技术选型详解
做毕设或者小型项目，技术栈最怕贪多嚼不烂。停车场管理系统用一套“保守又有活力”的组合最稳妥。
后端核心框架：SpringBoot 2.7.x。为什么不用3.x？因为3.x要求JDK17起步，部分教学环境和服务器的JDK版本还是8或11，2.7.x搭配JDK8是兼容性最好的组合。如果新机器且确信JDK版本没问题，也可以用新版本。
持久层框架：MyBatis Plus。相比原生的MyBatis，它提供了内置的CRUD方法，不需要手写基础的insert、selectById、updateById，大幅减少样板代码。代码生成器还能自动根据数据库表生成实体类、Mapper、Service、Controller，对开发效率的提升非常明显。
数据库：MySQL 5.7或8.0都行。如果没什么特殊偏好，建议直接8.0，字符集用utf8mb4，避免中文和特殊符号存储出问题。
前端框架：考虑到大多数人做毕设没精力手写复杂前端，AdminLTE或Vue2 + Element UI是比较现实的选项。如果更看重快速完成和稳定性，直接在Thymeleaf模板引擎里写管理后台也是可行方案。我的建议是：如果前后端分离有把握，就用Vue + Element UI，展示效果更好；如果想省事，就用服务端渲染，部署运维更简单。
其他组件：JWT做登录认证和Token校验，Hutool做工具类集合，EasyPOI或POI做Excel导入导出，ECharts做报表图表，Lombok简化实体类代码。
3.2 开发环境准备
无论你是直接在Windows上开发，还是用Linux服务器部署，环境准备都有固定套路。我按Windows开发机为例列一下：
- JDK 1.8（注意配置JAVA_HOME环境变量）
- Maven 3.6+（配置阿里云镜像加速依赖下载）
- MySQL 5.7/8.0（本地安装或Docker启动都行）
- IDEA 2022+（安装Lombok插件）
- Navicat或DBeaver（用于可视化操作数据库）
- Redis（如果做验证码缓存、Token黑名单这些附加功能才需要，纯毕设可跳过）
装好这些之后，在SpringBoot的application.yml里配置数据源、MyBatis Plus、日志级别这些基本信息。一个常用的基础配置长这样：
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/parking_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: root jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里的map-underscore-to-camel-case配置尤其重要。数据库字段通常是下划线风格，比如entry_time，Java属性是驼峰风格entryTime，开启这个配置后就能自动映射，省去一大堆@TableField注解。
3.3 项目目录结构规划
做任何SpringBoot项目，目录结构一开始就要定好，不然后期代码越来越乱，改一处崩三处。
src/main/java/com/example/parking/ ├── common/ // 通用类：统一返回结果、异常处理、常量定义 ├── config/ // 配置类：WebMvcConfig、MybatisPlusConfig、CorsConfig ├── controller/ // 控制层：接收前端请求 ├── service/ // 业务层：核心业务逻辑 │ └── impl/ ├── mapper/ // 数据访问层：MyBatis Plus的Mapper接口 ├── entity/ // 实体类：和数据库表对应 ├── dto/ // 数据传输对象：接收前端参数、返回前端数据 ├── vo/ // 视图对象：前端展示需要的数据结构 ├── utils/ // 工具类：日期处理、金额计算等 └── ParkingApplication.java // 启动类很多新手会把大量业务逻辑直接写在Controller里，让Controller变成“上帝类”。这在项目小的时候看不出问题，但一旦功能多起来，维护就是灾难。我坚持推荐三层架构：Controller只做参数接收和结果返回，Service写业务逻辑，Mapper操作数据库。这样分工清晰，答辩时讲代码结构也更有说服力。
4. 核心业务功能实现与代码解读
4.1 登录认证与权限控制
停车场系统面向的操作员主要是内部员工，登录认证用JWT是比较标准的选择。流程是：用户提交账号密码，后端校验通过后生成Token返回前端；前端后续请求在请求头里带上Authorization: Bearer <token>；后端通过拦截器解析Token，识别当前用户身份和角色。
关键代码大致是这个思路：
@PostMapping("/login") public Result login(@RequestBody LoginDTO loginDTO) { User user = userService.findByUsername(loginDTO.getUsername()); if (user == null || !BCrypt.checkpw(loginDTO.getPassword(), user.getPassword())) { return Result.error("用户名或密码错误"); } if (user.getStatus() == 0) { return Result.error("账号已被禁用"); } String token = JwtUtil.generateToken(user.getId(), user.getUsername(), user.getRole()); return Result.success(token); }密码存储用BCrypt加密，不是MD5。因为BCrypt自带随机盐，同样的密码每次加密结果都不同，即使数据库泄露，彩虹表也解不开。这一点在论文里可以重点写一写，评委老师普遍认可这种安全意识。
权限控制方面，用拦截器做粗粒度的登录校验，用注解配合切面做细粒度的角色校验。例如给管理员接口加上@RequireRole("ADMIN")注解，切面里检查当前用户角色是否匹配。
4.2 车辆入场与车位分配
车辆入场是最有业务感的一个功能，也是面试官最爱追问的流程之一。正常的入场流程是：
- 操作员输入（或摄像头识别）车牌号
- 前端请求后端入场接口，带上车牌号、通道号
- 后端判断车辆是否已在场内（防止重复入场）
- 查询空闲车位，自动分配或手动指定
- 更新车位状态为占用，插入入场记录
- 返回入场记录详情，前端展示分配的车位号
对应代码逻辑大致如下：
@Transactional public EntryRecordDTO handleEntry(EntryRequestDTO dto) { // 1. 防重复入场 Long count = entryRecordMapper.countUnfinishedByPlate(dto.getPlateNumber()); if (count > 0) { throw new BusinessException("该车辆已在场内，请勿重复入场"); } // 2. 自动分配一个空闲车位 ParkingSpace space = parkingSpaceMapper.selectFirstFreeSpace(); if (space == null) { throw new BusinessException("当前无空闲车位"); } // 3. 原子更新车位状态，防止并发覆盖 int affected = parkingSpaceMapper.updateStatusWithCondition(space.getId(), 1, 0); if (affected == 0) { throw new BusinessException("车位已被占用，请重新分配"); } // 4. 插入入场记录 EntryRecord record = new EntryRecord(); record.setPlateNumber(dto.getPlateNumber()); record.setSpaceId(space.getId()); record.setEntryTime(new Date()); record.setEntryChannel(dto.getChannel()); record.setStatus(0); // 0=未出场 entryRecordMapper.insert(record); return convertToDTO(record, space); }注意我在这段代码里加了@Transactional注解，入场操作同时涉及车位状态更新和记录插入，要么都成功，要么都失败，不能出现“车位标记为占用但记录没写进表”的脏数据。
4.3 出场结算与收费计算
出场结算的核心是费用计算。费用规则不同，计算方式就不同。最常用的模式是“按时段累加计费”，比如：首小时5元，之后每小时3元，单日封顶30元，免费停车15分钟。
我建议把费用计算单独抽成一个ChargeCalculator类，这样后续扩展新规则时，不需要动原有代码。具体实现上，可以用策略模式，也可以用简单的if-else加规则参数。对毕设项目，策略模式稍显复杂，但代码看起来更专业。简易版本可以先这样写：
public BigDecimal calculate(ChargeRule rule, LocalDateTime entryTime, LocalDateTime exitTime) { long minutes = Duration.between(entryTime, exitTime).toMinutes(); if (minutes <= rule.getFreeMinutes()) { return BigDecimal.ZERO; } // 按自然日拆分，每日单独计算，最后累加 // 这是一种比较稳健的做法，能正确覆盖跨天停车场景 List<DaySegment> segments = splitByDay(entryTime, exitTime); BigDecimal total = BigDecimal.ZERO; for (DaySegment segment : segments) { total = total.add(calcDayAmount(rule, segment)); } // 超过封顶金额则取封顶 if (rule.getCapAmount() != null && total.compareTo(rule.getCapAmount()) > 0) { return rule.getCapAmount(); } return total; }这里“按自然日拆分”是我实际开发中踩过坑之后总结出来的。如果直接算总停了多少小时，再乘以单价，跨天停车时费用会算错，因为每天的封顶额度应该是独立的。比如停了一天半，必须第一天扣30，第二天扣一部分，而不是整个时间段统一算15小时然后超过30直接封顶——那样第二天就变成免费了。
出场结算完成后，要做三件事：更新入场记录状态为“已出场”、插入出场记录、释放车位状态。这三步同样放在一个事务里。
4.4 月租用户与免费策略
月租车的逻辑和临时车完全不同。月租车入场时不需要分配计费，出场时也直接放行。但月租车有有效期，过期后要自动转为临时车收费模式。
比较常见的设计是为vehicle_info表增加一个card_expire_time字段。入场时判断是否月租车：
if (vehicle != null && vehicle.getCardExpireTime() != null && vehicle.getCardExpireTime().isAfter(LocalDateTime.now())) { // 月租有效，直接入场不参与计费 }出场时同样判断月租有效性。如果月租已过期，则按临时车标准收费。这样做的好处是：逻辑上不搞两套入场体系，只是费用计算时走不同分支，代码复杂度控制得住。
4.5 前端管理页面设计
后端做得再稳，前端页面太简陋也影响整体印象分。停车场管理系统的核心页面我建议做成这样几个：
- 登录页：简洁的登录表单，带验证码
- 工作台/首页：展示今日车流量、当前在场车辆数、今日收入、车位利用率
- 车辆管理页：车牌号搜索、在场车辆列表、一键入库/出库操作
- 车位管理页：用宫格或表格展示车位状态，区分颜色标识空闲、占用、停用
- 收费规则页：可视化配置计费规则
- 财务报表页：按日/月走势图、收入明细表格
前端如果选Vue + Element UI，这些页面写起来其实不复杂。用ECharts画趋势图，数据从后端统计接口拉取。注意跨域问题，在后端配置全局CorsConfig或者在application.yml里设置允许跨域的路径。
5. 部署上线与性能优化要点
5.1 本地打包与服务器部署
毕设项目到答辩阶段，老师通常会要求“能跑起来看到效果”。在本地IDEA里跑通只是第一步，我建议你把打包部署的过程也走一遍，一方面答辩时可以展示部署能力，另一方面也能提前躲开“本地能跑，部署就挂”的经典坑。
打包方式很简单，在项目根目录执行：
mvn clean package -DskipTests生成的JAR包在target/目录下。把这个JAR包扔到服务器上，用一行命令就能启动：
java -jar parking-system.jar --spring.profiles.active=prod但这里有个大坑：如果你的application.yml里配置了绝对路径的日志目录、静态资源上传路径，换到服务器上就会报“找不到路径”。我建议把这些路径配置全部移到application-prod.yml里，用服务器上的绝对路径重写一份。本地开发用默认配置，上线用prod配置，两不误。
5.2 数据库索引与SQL优化
停车场系统的数据量虽然不至于到海量，但索引该建还是要建，尤其是以下几种高频查询场景：
- 查询车辆是否在场：按
plate_number查entry_record，所以入场记录表要建idx_plate_number索引 - 查找空闲车位：按
status和space_type查parking_space，建立联合索引 - 统计报表：按
entry_time范围查入场记录，时间字段加索引很有必要
有一个常见的性能问题：停车场系统报表页面经常要按日期范围汇总数据，SQL里很自然地写WHERE entry_time BETWEEN ? AND ?。如果时间字段没索引，全表扫描，数据过了几万条后报表页会肉眼可见地变慢。加了索引之后，基本秒开。
另外，MyBatis Plus的selectList默认是查出全字段。如果某张表有20个字段，但业务里只需要5个，建议用select(Wrapper)指定列，减少数据库到应用之间的数据传输量。
5.3 并发场景下的数据安全
停车场系统在早晚高峰期有并发操作需求，尤其是“同一车位同时被两个请求占用”的情况。之前写的原子更新SQL已经解决了这个问题。但还有一个隐含风险：同一辆车在极短时间内反复提交入场请求。
防重复这个动作，最稳妥的方式是在应用层加分布式锁或使用数据库唯一索引。对毕设项目，加一张entry_record表，并在plate_number上加“部分唯一索引”是不好实现的，因为同一辆车在不同时间可以多次入场。正确的做法是加一个逻辑校验：查询是否有状态为0（未出场）的记录存在，有则拒绝。加上事务隔离和代码里的先查后插，正常情况下已经足够。
如果你想展示更高级的方案，可以在入场接口里用Redis的setIfAbsent做一键锁：
Boolean locked = redisTemplate.opsForValue() .setIfAbsent("lock:entry:" + plateNumber, "1", 3, TimeUnit.SECONDS); if (!Boolean.TRUE.equals(locked)) { throw new BusinessException("请勿重复提交入场请求"); }这个方案写进论文里，技术含量一下子就上来了。
6. 常见问题排查与避坑经验
6.1 时间日期与夏令时踩坑
停车场系统大量涉及时间计算，日期处理的坑最隐蔽，也最致命。最常见的错误是把时间字段用字符串直接存储，然后通过字符串减法来计算时长。这种方案在格式统一时勉强能用，但跨天后就完全不可控。
我的规范是：实体类里时间字段一律用LocalDateTime，数据库字段一律用datetime类型，Jackson统一配置yyyy-MM-dd HH:mm:ss格式。计算时长用Duration.between()，不做任何手工字符串处理。
另外要注意MySQL连接串里serverTimezone=Asia/Shanghai这个参数。不配的话，数据库读出来的时间可能会比真实时间少8小时或者多8小时，具体方向取决于服务器和客户端时区配置。这个坑在系统上线后出现，排查成本极高。
6.2 停车费用精度问题
金额计算一定要用BigDecimal，绝不能用double或float。原因很简单：0.1 + 0.2在二进制浮点里不是精确的0.3，而停车费这种涉及钱的场景，一分钱的误差都可能引发客诉。
MyBatis Plus操作数据库时，注意数据库字段要定义成decimal(10,2)。代码中定义实体字段用BigDecimal，插入和查询不会出现精度丢失。如果出现“金额多了0.01”的问题，优先检查是不是用了double做中间计算。
6.3 车辆重复入场与出场失败的边界处理
实际运营中总会遇到一些边界情况。比如车辆入场后识别失败，操作员手工录入车牌；比如出场时道闸故障，车辆没正常离场。系统设计上一定要考虑操作员的手动修正能力，至少提供一个“异常出场”功能，允许管理员强制关闭一笔未完成的入场记录，并补充说明原因。
我在一个实际项目里就遇到过：某辆车入场后，出场记录因为支付超时没有成功落库，结果导致该车辆在系统里一直处于“在场”状态，下次入场就被拦截。解决办法是提供一个“在场车辆异常处理”的后台功能，管理员可以查看所有在场车辆，对异常记录执行强制出场。
这也是答辩时可以重点讲的一个场景，体现你对业务边界的思考。
6.4 常见问题速查表
| 问题表现 | 可能原因 | 排查思路 |
|---|---|---|
| 启动报“Failed to configure a DataSource” | 数据源配置缺失或数据库服务未启动 | 检查application.yml数据源配置，确认MySQL服务状态 |
| 中文乱码 | 数据库字符集不是utf8mb4 | 修改数据库和数据表的字符集为utf8mb4 |
| 查询出的时间比实际少8小时 | 连接串未配置serverTimezone或时区错误 | 连接串加serverTimezone=Asia/Shanghai |
| 同一车位同时分配给两辆车 | 未使用原子更新的状态SQL | 改为UPDATE ... WHERE status = 0 |
| 跨天停车费用计算错误 | 未按自然日拆分计费 | 实现按日拆分的计费逻辑 |
| 前端跨域请求失败 | 未配置CORS或配置错误 | 添加全局CorsConfig，允许前端域名 |
| 打包后运行报“no main manifest attribute” | 缺少SpringBoot插件或打包配置错误 | 检查pom.xml中是否引入spring-boot-maven-plugin |
7. 项目扩展方向与个人经验分享
7.1 从毕设到生产级应用的演进思路
如果你做完这个项目之后还有余力，或者在答辩时想让系统更有亮点，有以下几个扩展方向值得考虑。
接入车牌识别能力。目前系统是纯手输车牌的模式，你可以通过调用第三方开放平台的OCR能力，或者接入本地的车牌识别SDK，实现摄像头抓拍自动识别车牌。这样可以减少操作员的工作量，也让“智慧停车”的定位名副其实。这个功能在答辩时很容易引起评委兴趣，而且实现思路并不复杂——只是把“识别出的车牌号”作为参数传给入场接口。
增加小程序端。给车主做一个简单的小程序，实现绑定车牌、查询停车记录、在线缴费、月卡续费。SpringBoot后端基本不用大改，新增几个面向C端的接口就行，前端用微信小程序原生写或者uni-app都可以。这个是当前行业较常见的需求方向，很多停车场已经把“扫码缴费”作为标配功能。
引入消息队列处理高并发入场统计。如果日均车流量上万，统计报表的实时性要求很高，可以考虑引入RabbitMQ或Kafka，把入场事件先推到队列，由消费者异步更新统计数据，避免高峰期直接查库导致数据库压力过大。对毕设来说这个方向有些超前，但作为扩展设计写进论文展望里是加分的。
7.2 我对这套系统的一线实操心得
这类型的项目中，我花时间最多的地方不是写代码，而是捋业务规则。说句实话，停车场的计费规则比很多人想象中复杂得多——早高峰免费、夜间优惠、单日封顶、跨天叠加、特殊节假日折扣，这些规则相互叠加的时候，逻辑链特别容易乱。
我一贯的做法是：对每一种收费场景都提前用表格列出来，写出预期结果，再让系统跑出实际结果，两者对比。比如“入场时间为周五23:50，出场时间为周六00:30”，预期结果是什么？如果是首小时免费，那这40分钟不收钱；如果按自然日计费，周五和周六各算一段。这些边界情况必须先把规则定清楚再动代码，否则后期改起来非常痛苦。
另外还有一点，项目做完后一定要把数据库的初始化脚本、部署文档、README一并整理清楚。很多选手做毕设只交了源代码，结果答辩时老师想跑起来看效果，连数据库都没法新建，印象分大打折扣。我建议把schema.sql和data.sql放在项目根目录的sql/文件夹里，写清楚从零启动的完整步骤。这不仅是给评审老师看的，也是你工程素养的直接体现。
7.3 最后的一个小技巧
最后分享一个对答辩特别有用的小技巧：在项目里加一个全局的“系统操作日志”功能。不需要很复杂，用一个AOP切面拦截所有Controller请求，记录操作人、操作时间、操作内容、请求参数。答辩时演示一下“所有操作都可追溯”，评委基本都会点头认可。
实现很简单，在pom.xml里引入AOP依赖，写一个切面类：
@Aspect @Component public class OperationLogAspect { @Around("@annotation(operationLog)") public Object recordLog(ProceedingJoinPoint pjp, OperationLog operationLog) throws Throwable { // 记录开始时间 long start = System.currentTimeMillis(); // 执行业务逻辑 Object result = pjp.proceed(); // 记录耗时和操作内容 log.info("操作:{}, 耗时:{}ms", operationLog.value(), System.currentTimeMillis() - start); return result; } }这个功能看起来不起眼，但对系统整体质量的提升是立竿见影的。一套停车场管理系统，从需求分析到数据库设计再到功能实现，最终能拿出的不只是代码，而是一个真正能落地、能演示、能讲清楚来龙去脉的完整项目。这就是我对这类SpringBoot实战项目的核心理解。
