每年到毕业设计选题季总有同学在各种系统里纠结犹豫。校园智能停车系统是我见过最能打的一组选题业务场景真实、用户角色清晰、技术栈覆盖全面而且停车这个事儿人人都能共情答辩时业务说得清楚代码也有得聊。这套基于 Spring Boot 的实现从车位状态流转、预约并发控制到计费结算把一个完整业务系统该有的难点都踩了一遍。这篇文章就从需求建模到核心代码把这个项目完整拆一遍该给的表结构、关键流程、代码片段、坑位记录都放出来给做这个选题的同学一个能直接参考的底稿。1. 项目到底要做什么需求拆解与业务建模1.1 校园停车场景的特殊性校园停车场和商业综合体、写字楼的停车场差别很大。万不得已不能用商业停车场的逻辑直接套校园场景否则做出来的系统看着像个壳子答辩的时候一问业务就说不过去。校园停车有几个非常明显的特征。第一个是潮汐性极强。早晨上课前和下午下课后是两波进出高峰中间时段车位闲置率很高。第二个是用户群体固定以教职工和学生为主外来临停车辆比例低。第三个是管理规则多样有月卡、临时计费、教职工免费时间段、特种车辆备案、活动期间预留车位等规则不是死板的固定价格而是组合式策略。这些特征直接决定了系统的核心业务方向。车位管理不能是简单的“空/占用”两态需要包含“锁定”、“预约”、“预留”等中间状态。普通停车场只需要车来了分配车位校园停车要考虑“车辆还没来但车位已经预约出去”的状态管理。第四个特征是校园停车场这种半封闭管理场景里信息化系统的核心价值不在“赚钱”而在“调度”。学校建停车场不是为了收那点停车费是要解决教职工上班找不到车位的问题。所以系统应当优先保证预约成功率、提高车位周转率而不是追求最高的费用收益。1.2 用户角色划分与核心流程市面上的停车系统大多只做两个角色管理员和用户。但校园场景要拆得更细。教师通勤车辆需要高峰期保障学生车辆更多是临时停放访客和送货车辆则是完全不同的审批路径。如果都用一个角色模型去套前面提到的业务规则根本落不下去。我建议至少拆成四个角色系统管理员、教师用户、学生用户、访客。系统管理员负责基础数据维护包括停车场与车位信息、计费策略配置、用户审核、车辆白名单管理、订单异常处理、系统报表查看。教师用户和学生用户的差异体现在预约优先级和计费策略上比如高峰期教师预约配额更高、教师月卡价格和学生月卡不同等。访客用户则是临时车牌登记预约时长受限部分区域直接不可预约。核心业务流程可以梳理成一条主线用户注册并绑定车牌号之后在小程序或Web端查看实时车位图选择空闲车位发起预约系统锁定车位并生成预约订单。用户在规定时间内到场入口设备识别车牌后自动放行系统自动将订单状态从“待入场”流转为“停车中”开始计时计费。出场时再次识别车牌结算费用完成订单归档。这条流程里每一步其实都对应着数据库里的状态流转后面我会专门讲状态机和并发控制那是整个系统成败的关键。很多同学把停车系统做成了简单的“增删改查”问题就出在没有把这个状态流转模型想清楚。1.3 毕业设计视角的评分点与选题优势从毕设评分角度说这种选题有两个天然优势。业务具备复杂度但难度可控既不会像简单信息管理系统那样被挑刺说没有技术含量又不会像分布式中台那种工程把学生难倒。另一个是展示效果好。同样做管理系统如果只是把数据表格CRUD一遍答辩现场很干。停车系统至少有实时车位可视化、预约流程演示、计费结算动态过程演示起来直观。不过评分点也意味着硬性要求。逻辑完整度是第一位一个业务流程必须首尾连贯预约、入场、出场、结算、归档一个环节不能少。其次是数据一致性车位会不会被超卖、预约会不会丢单这些是考核技术深度的核心。第三是工程规范度项目结构、代码分层、接口注释、异常处理这些细节都会被翻出来看。第四才是界面美观度但界面也不能拖后腿。从功能层面看校园智能停车系统要想做到“能打”的完成度我的建议是至少覆盖以下模块模块功能要点重要程度用户认证注册、登录、权限角色管理、车牌绑定高停车场管理车库/区域配置、车位状态维护、可视化展示高预约模块查询空闲车位、预约、入场确认、取消核心停车记录入场识别登记、出场结算、历史明细核心计费系统计费规则引擎、月卡管理、费用减免高统计分析车位利用率、周转率、收入报表中等消息通知预约成功、超时提醒、月卡到期加分项能满足这套功能矩阵系统已经具备完整业务闭环答辩时无论老师从哪个环节切入提问都有代码可以对应。2. 技术选型为什么是Spring Boot这套组合2.1 后端核心组件与版本搭配项目标题里已经锁定了 Spring Boot 作为基底。Spring Boot 2.7.x版本是当前校园项目里最稳的我的建议是不要盲目追新用 Spring Boot 3.x。Spring Boot 2.7 基于 JDK 8环境兼容性最好学校机房、个人电脑装的环境五花八门JDK 8 是最不容易出问题的。如果非要用 Spring Boot 3就得强迫所有人升到 JDK 17光这一项就能劝退一批人。持久层框架有两条路线MyBatis-Plus 和 Spring Data JPA。两者我各用过一段时间只做毕业设计的话我更推荐 MyBatis-Plus。原因是这框架的代码量省得非常可观单表CRUD完全不用自己写 SQL分页查询一行搞定而且 LambdaQueryWrapper 对新手阅读代码更友好。JPA 虽然也很强大但很多同学理解不了持久化上下文和懒加载一查数据就报毛病调试成本太高。数据库选 MySQL 8.0这是标配没什么争议。缓存组件引入 Redis用于车位状态缓存和分布式锁。这里我可以给一个小建议如果只是做单人毕设Redis 环境自己电脑装好就行但如果想在答辩现场展示“高并发解决”的思路Redis 是不可省略的环节。版本搭配我用实际组合做个参考组件版本说明JDK1.8稳定性优先Spring Boot2.7.182.x 最后一个稳定版MyBatis-Plus3.5.3含分页插件MySQL8.0.32InnoDB 引擎Redis6.2 以上缓存与锁Swagger/Knife4j4.x接口文档JWTjjwt 0.9.1无状态登录认证2.2 前端方案小程序还是Web后台前端方向的选择会直接影响整个项目的开发节奏。常见方案有微信小程序、Vue管理后台和 Thymeleaf 服务端渲染。我负责任地说如果是个人独立开发且时间有限最高效的组合是前端做两个端用户端用微信小程序管理端用 Vue Element Plus 的页面内嵌到项目里。但两者都做工作量不小需要取舍。更务实的降级方案是用户端用移动端适配的 H5 页面管理端用 Vue 独立项目。这样的好处是用户端和管理端复用了同一套 API后端开发专注逻辑前端用成熟的组件库快速搭建。Thymeleaf 服务端渲染的制作成本最低但页面效果确实一般答辩时视觉分容易吃亏。如果以前从没写过小程序我建议不要逞强。小程序从注册账号、审核类目到真机调试有一套独立的流程复杂度这些麻烦在临近答辩时会很折磨人。相比之下 H5 页面放到校园网络环境里直接浏览器访问效果一样能打。做毕设的核心思维是控制全流程中的不确定性而不是追求技术栈的时髦。2.3 数据库设计核心表结构剖析数据库设计是整个项目最值得花时间的地方。表结构设计得好后面写代码就是填逻辑设计得烂后面每写一个查询都像在补窟窿。我把核心表结构拿出来逐一分析。用户表保存账号信息和角色类型这里要注意的是用户和车辆是多对一关系一个用户可能绑定多辆车。车辆表之所以单独拆出来是为了配合车牌识别业务。当你设计停车场设备对接时进门摄像头扫到车牌系统要通过车牌反查用户信息这个字段天然是高频查询位必须加索引。车位表是最关键的一张表。字段不能只存一个“状态”我建议用状态字段加预约ID加锁定时间的组合来设计。车位状态至少包含空闲、占用、预约、锁定四种。有个很多初学者不会提前想到的场景线下保安叔叔手动把一个没预约的车放进了一个有预约的车位这种状况如果系统没有保留操作记录的能力业务就崩了。因此车位表里要冗余一个当前占用记录ID的字段方便追溯。预约表服务预约流程核心字段包括车位ID、用户ID、预约开始时间、入场截止时间、状态、订单号。计费需要订单表一个预约单对应一个停车订单入场时创建出场时计算费用。规范的做法是把预约和停车分为两张表用订单号关联因为实际业务里预约可能取消停车订单仍然独立存在。还有一张容易被忽略的是规则表。计费规则如果不配置而是写死在代码里那系统就废了。校园停车规则多样性决定了必须建一张规则表支持配置时段、车型、用户类型、计费单价和封顶金额。这样改收费策略不用动代码改配置就行答辩现场说“计费策略可配置”也是一句漂亮话。3. 核心功能怎么落地关键代码与业务逻辑3.1 车位实时状态与并发控制停车系统最怕的车位超卖问题。假设当前车位状态显示空闲两个用户同时提交预约请求如果代码只做“查询-判断-更新”三步操作数据库层面必然出现两个事务都读到空闲状态然后双双更新成功一个车位就约给了两个人。解决思路要从数据库层面下手。MySQL提供了悲观行锁机制在处理预约占位这种强一致场景下直接对车位行加锁是最直观可靠的方案。public synchronized boolean lockParkingSpace(Long spaceId, Long userId) { // 使用悲观锁查询时对车位行加写锁 ParkingSpace space parkingSpaceMapper.selectByIdForUpdate(spaceId); if (space null || !FREE.equals(space.getStatus())) { return false; } // 更新车位状态为锁定记录预约用户ID space.setStatus(LOCKED); space.setLockUserId(userId); space.setLockTime(new Date()); parkingSpaceMapper.updateById(space); return true; }上面的方法里selectByIdForUpdate 对应 MyBatis-Plus 自定义 SQL 中的 SELECT ... FOR UPDATE。这是数据库锁禁忌里最该学会的一个操作。只要注释掉 FOR UPDATE回表校验就形同虚设。事务边界也要格外注意锁定的生命周期必须包含整个业务逻辑。如果把 Transactional 加在 Service 层方法上方法运行期间持有数据库锁方法结束落库后锁才释放。这写法的好处是极端并发下也不出错代价是并发吞吐量降低。毕业设计场景下这种取舍完全没问题反而在答辩时可以清晰地说出自己如何解决线程安全问题。3.2 预约流程与锁的整合实现预约操作不是一个简单的状态更新它是一串连贯动作的组合查车位、创建预约单、锁定车位、更新用户预约数量。这串动作要么全部完成要么全部不生效。我把它们放进同一个事务里用 Spring 的声明式事务来控制。Transactional(rollbackFor Exception.class) public AppointOrder createAppointment(AppointmentDTO dto) { // 1. 锁定车位行 ParkingSpace space parkingSpaceMapper.selectByIdForUpdate(dto.getSpaceId()); if (space null || !FREE.equals(space.getStatus())) { throw new BusinessException(车位已被占用请重新选择); } // 2. 车位状态流转FREE - LOCKED space.setStatus(LOCKED); space.setLockTime(new Date()); parkingSpaceMapper.updateById(space); // 3. 创建预约单入场截止时间为当前时间 15分钟 AppointOrder order new AppointOrder(); String orderNo AP System.currentTimeMillis() RandomUtil.randomNumbers(4); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setSpaceId(dto.getSpaceId()); order.setStatus(WAIT_ENTRY); order.setEntryDeadline(new Date(System.currentTimeMillis() 15 * 60 * 1000)); appointOrderMapper.insert(order); // 4. 记录流水方便审计 SpaceOperateLog logRecord new SpaceOperateLog(); logRecord.setSpaceId(spaceId); logRecord.setOperateType(APPOINT); logRecord.setOrderNo(orderNo); spaceOperateLogMapper.insert(logRecord); return order; }注意一个关键点代码里的 15 分钟入场截止时间是写死的被我用了常量替代实际项目中建议从配置表读取。校园不同区域可能入场缓冲时长不一样比如说教学区地下车库一般提前 15 分钟截止而宿舍区可以放宽到 30 分钟。这个可配置往细节里做就可以在答辩报告中作为一个设计亮点。3.3 计费策略与结算引擎计费引擎是停车场系统里逻辑最有意思的部分。表面看是单价乘时长但真实的校园计费规则极其琐碎自由组合时很容易把代码写成 if-else 地狱。合理做法是把计费拆成两条线基础计价线负责计算时长相关费用附加策略线负责叠加用户身份、时段、减免等规则。public FeeResult calculateFee(ParkingOrder order, User user) { long minutes computeParkingMinutes(order); // 1. 基础费用按小时单价向上取整不足整小时按整小时计 FeeRule baseRule feeRuleMapper.selectBaseRule(order.getParkingLotId()); BigDecimal baseFee BigDecimal.valueOf(minutes) .divide(BigDecimal.valueOf(60), 0, RoundingMode.CEILING) .multiply(baseRule.getUnitPrice()); // 2. 优惠叠加教职工 8 折学生无折扣 if (TEACHER.equals(user.getRole())) { baseFee baseFee.multiply(new BigDecimal(0.8)); } // 3. 封顶校验单日最高 20 元超过则按封顶计 BigDecimal dailyCap feeRuleMapper.selectDailyCap(); if (baseFee.compareTo(dailyCap) 0) { baseFee dailyCap; } return new FeeResult(baseFee); }这些规则我看着简单放代码里也很短但实际落地时踩坑的地方全在细节。比方说“不足整小时按整小时计”的取整方式我见过好多同学用的普通四舍五入把一个小时的停车取整成了半小时对不上账单。这里的核心就是计算过程中必须注意 BigDecimal 的 scale 和 rounding mode不然你会被自己的账单数据折磨到崩溃。费用减免也不是简单扣一笔钱就完了还牵扯到费用减免的审批记录。谁减的、为什么减、减多少这些都必须留在表里。这部分的工程严谨性很可能成为答辩时老师问你的区别度。3.4 定时任务处理预约过期问题预约过期释放是毕业设计里必现的一个问题。用户预约了车位但有事没来这个车位要是一直锁着其他用户就完全没法用。解决思路是引入定时任务定期扫描超时未入场的预约并释放车位。Spring Boot 原生提供了 Scheduled 注解简单易用。在启动类上加上 EnableScheduling然后在服务类中配置一个每 30 秒执行一次的扫描任务。这里有一个工程上容易忽略但实际很重要的点定时任务在多节点部署时会重复执行如果同一个任务在多个实例上同时运行车位释放就会被重复处理。项目里我引入 ShedLock 来给定时任务加分布式锁这样多实例下任务只在一个节点上执行其他节点处于等待状态。虽然毕设场景基本是单机部署但把这个方案写进设计文档老师看到了会认为你具备分布式思维。另一个坑是任务启动时跑在了业务高峰前大量扫描任务并发执行把数据库索引没打好的表拖垮。优化思路是给预约表的入场截止时间字段加上精度合适的索引扫描 SQL 按时间范围限定避免全表扫描。4. 从坑到路接口设计规范与前后端联调的实践经验4.1 统一返回值与异常体系很多同学的代码里后端返回数据的格式五花八门。有时候返回 Map有时候返回 JSONObject有的查询成功返回 null有的又返回数组直接前端判断。前后端联调一半时间浪费在互相猜数据结构上这种体验极差。我落地这个项目时做的第一件事就是统一了一套返回规范。所有接口返回 R 对象包含 code、message、data 三个字段。code 为 0 表示业务成功其他为业务异常码。Getter public class RT { private Integer code; private String message; private T data; public static T RT ok(T data) { RT r new R(); r.code 0; r.message success; r.data data; return r; } public static T RT fail(Integer code, String message) { RT r new R(); r.code code; r.message message; return r; } }前端统一对 res.code 做判断不需要针对每个接口单独处理 errror 分支大大压缩了联调沟通成本。后端代码里所有业务异常都通过抛出 BusinessException 来标记配合 ControllerAdvice 全局异常处理器统一转成 R 对象返回。4.2 JWT认证与拦截器配置校园停车系统里有用户角色区分接口权限天然要分级。管理员接口和管理员页面对一般用户不能开放。我用 JWT 做无状态登录认证用户登录成功后后端签发 token前端每次请求在 header 里带上后端拦截器解析鉴权。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 )) { throw new BusinessException(401, 未登录); } Claims claims JwtUtil.parseToken(token.substring(7)); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } }这个拦截器主要做三件事解析 token、注入用户上下文、校验 token 状态。权限更高的角色判断我用独立注解完成比如 RequireRole(ADMIN) 加在方法上由另一个切面去校验角色字段。这块设计好之后后面所有接口只需要在需要管理员权限的地方加注解不用重复写 if 判断。4.3 联调中最容易翻车的细节前端联调阶段是我整个项目里踩坑最多的阶段。总结几个高频问题供大家避坑。跨域是首当其冲的问题。前端开发服务器跑在局域网某端口后端跑在另一端口直接发请求一定被 CORS 拦截。后端这里我用 WebMvcConfigurer 统一加入了跨域配置并且设置 allowedOriginPatterns 而不是 allowedOrigins。很多人用 allowedOrigins 配多个来源时发现怎么配都报错原因可能是 allowCredentials 与 allowedOrigins 规则在当前 Spring 版本中互斥需要改成 allowedOriginPatterns 来组合使用。第二个坑是时间格式化导致的时区偏移。后端返回的时间是 UTC 时间前端拿到后显示成了之前的时间计费记录看上去全错了。这个问题的根源是 Jackson 序列化时间时没有统一时区。我在 application.yml 里固定了时间格式和时区参数前后端统一用北京时区处理。第三个坑是 MyBatis-Plus 分页查询不生效。很多同学的代码里写了 Page 对象传进 selectPage 方法结果返回的数据还是全量。这个问题的根因是没注册 MyBatis-Plus 的分页插件。这个插件必须通过 MybatisPlusInterceptor Bean 显式配置文件不加分页插件Page 对象就形同虚设。这个坑我在别的项目里也遇见过印象非常深刻。这三个问题属于那种网上搜索可能一时半会儿找不到答案但在联调阶段又必然会遇上。提前写在代码注释里对将来的维护也是一种提醒。5. 从功能到亮点让项目不止于可运行5.1 低成本加分的三个进阶方向纯 CRUD 的停车系统答辩分数基本就在及格线上徘徊。想拉开差距不见得非得引入微服务或者各种重型框架价格又便宜效果又好的方向有三个。第一个是车位热力图。把每天各个时段的车位占用率统计出来用前端可视化组件渲染成热力图。这个功能背后对应的就是 SELECT 语句按小时 GROUP BY 统计再配合 Redis 缓存热点数据工作量不多答辩现场展示效果极好。第二个是车牌识别演示区。真实停车场品牌车辆识别设备动辄数万元毕设总不能真去采购。但简化版完全可以做成前端上传一张车牌照片后端调用图像处理库做车牌裁剪和字符识别或者模拟识别过程再把这个识别结果回传到系统。相比接入第三方 API 或 SDK这个自研演示方案既可控又有技术含量。第三个是消息通知。预约成功、预约超时释放、月卡即将到期这些业务节点通过模板消息推送提醒用户。校园环境下天然适合接入邮件或企业角度的消息推送。实在不想接邮件服务也可以在系统内部做一个站内通知模块效果一样有故事性。5.2 答辩准备时容易被问到的位置答辩老师提问通常集中在几个高频位置数据库表关系、并发解决方案、定时任务设计、接口安全。我建议把设计文档里面关于这几块的内容单独提炼出来做几张图业务流程图和 ER 图是必须有画出来的。画图的时候用朴素的连接线说明关系不要画乱。图其实比代码更容易建立沟通语境。还有一个小诀窍任何时候不要说自己“界面不好看”。答辩时如果主动说界面丑老师真的会一直盯着界面不放。应该把重心拉到业务闭环和技术细节上界面单纯属于锦上添花的维度。5.3 我对这套项目最真实的感受如果你准备做这个项目我的总体建议是功能宁缺毋滥核心链路的正确性必须保证。宁可少做一个报表也要把“预约-入场-出场-结算”这条主线走到无懈可击。这里说的无懈可击包括数据状态不会出错、重复请求不会生成两条订单、并发预约不会超卖。这三个问题如果有任何一个处理不到位功能再多也白搭。做这个项目之前我对车位状态的理解很朴素以为就是“空着”和“占用”两种状态。真正把预约、锁定、超时、取消这些环节串起来之后才发现状态机设计才是整个项目中最值得反复斟酌的地方。能把这套状态流转想明白哪怕毕业之后不做停车场相关开发这套建模方法论放在别的事务型系统里一样通用。最后再分享一个实际调试中的小场景当时测试预约流程我左边开着小程序模拟器右边开着数据库表每操作一步就刷新一次表数据。预约、入场、出场、结算这一路释义下来表数据在小心地跟着业务流转而变化。那一刻突然觉得系统确实是活的所有写的逻辑是在支撑一个真实世界可以落地的场景。这种从页面到数据完整闭环的感觉可能才是毕业设计给你最大的收获。
每年到毕业设计选题季总有同学在各种系统里纠结犹豫。校园智能停车系统是我见过最能打的一组选题业务场景真实、用户角色清晰、技术栈覆盖全面而且停车这个事儿人人都能共情答辩时业务说得清楚代码也有得聊。这套基于 Spring Boot 的实现从车位状态流转、预约并发控制到计费结算把一个完整业务系统该有的难点都踩了一遍。这篇文章就从需求建模到核心代码把这个项目完整拆一遍该给的表结构、关键流程、代码片段、坑位记录都放出来给做这个选题的同学一个能直接参考的底稿。1. 项目到底要做什么需求拆解与业务建模1.1 校园停车场景的特殊性校园停车场和商业综合体、写字楼的停车场差别很大。万不得已不能用商业停车场的逻辑直接套校园场景否则做出来的系统看着像个壳子答辩的时候一问业务就说不过去。校园停车有几个非常明显的特征。第一个是潮汐性极强。早晨上课前和下午下课后是两波进出高峰中间时段车位闲置率很高。第二个是用户群体固定以教职工和学生为主外来临停车辆比例低。第三个是管理规则多样有月卡、临时计费、教职工免费时间段、特种车辆备案、活动期间预留车位等规则不是死板的固定价格而是组合式策略。这些特征直接决定了系统的核心业务方向。车位管理不能是简单的“空/占用”两态需要包含“锁定”、“预约”、“预留”等中间状态。普通停车场只需要车来了分配车位校园停车要考虑“车辆还没来但车位已经预约出去”的状态管理。第四个特征是校园停车场这种半封闭管理场景里信息化系统的核心价值不在“赚钱”而在“调度”。学校建停车场不是为了收那点停车费是要解决教职工上班找不到车位的问题。所以系统应当优先保证预约成功率、提高车位周转率而不是追求最高的费用收益。1.2 用户角色划分与核心流程市面上的停车系统大多只做两个角色管理员和用户。但校园场景要拆得更细。教师通勤车辆需要高峰期保障学生车辆更多是临时停放访客和送货车辆则是完全不同的审批路径。如果都用一个角色模型去套前面提到的业务规则根本落不下去。我建议至少拆成四个角色系统管理员、教师用户、学生用户、访客。系统管理员负责基础数据维护包括停车场与车位信息、计费策略配置、用户审核、车辆白名单管理、订单异常处理、系统报表查看。教师用户和学生用户的差异体现在预约优先级和计费策略上比如高峰期教师预约配额更高、教师月卡价格和学生月卡不同等。访客用户则是临时车牌登记预约时长受限部分区域直接不可预约。核心业务流程可以梳理成一条主线用户注册并绑定车牌号之后在小程序或Web端查看实时车位图选择空闲车位发起预约系统锁定车位并生成预约订单。用户在规定时间内到场入口设备识别车牌后自动放行系统自动将订单状态从“待入场”流转为“停车中”开始计时计费。出场时再次识别车牌结算费用完成订单归档。这条流程里每一步其实都对应着数据库里的状态流转后面我会专门讲状态机和并发控制那是整个系统成败的关键。很多同学把停车系统做成了简单的“增删改查”问题就出在没有把这个状态流转模型想清楚。1.3 毕业设计视角的评分点与选题优势从毕设评分角度说这种选题有两个天然优势。业务具备复杂度但难度可控既不会像简单信息管理系统那样被挑刺说没有技术含量又不会像分布式中台那种工程把学生难倒。另一个是展示效果好。同样做管理系统如果只是把数据表格CRUD一遍答辩现场很干。停车系统至少有实时车位可视化、预约流程演示、计费结算动态过程演示起来直观。不过评分点也意味着硬性要求。逻辑完整度是第一位一个业务流程必须首尾连贯预约、入场、出场、结算、归档一个环节不能少。其次是数据一致性车位会不会被超卖、预约会不会丢单这些是考核技术深度的核心。第三是工程规范度项目结构、代码分层、接口注释、异常处理这些细节都会被翻出来看。第四才是界面美观度但界面也不能拖后腿。从功能层面看校园智能停车系统要想做到“能打”的完成度我的建议是至少覆盖以下模块模块功能要点重要程度用户认证注册、登录、权限角色管理、车牌绑定高停车场管理车库/区域配置、车位状态维护、可视化展示高预约模块查询空闲车位、预约、入场确认、取消核心停车记录入场识别登记、出场结算、历史明细核心计费系统计费规则引擎、月卡管理、费用减免高统计分析车位利用率、周转率、收入报表中等消息通知预约成功、超时提醒、月卡到期加分项能满足这套功能矩阵系统已经具备完整业务闭环答辩时无论老师从哪个环节切入提问都有代码可以对应。2. 技术选型为什么是Spring Boot这套组合2.1 后端核心组件与版本搭配项目标题里已经锁定了 Spring Boot 作为基底。Spring Boot 2.7.x版本是当前校园项目里最稳的我的建议是不要盲目追新用 Spring Boot 3.x。Spring Boot 2.7 基于 JDK 8环境兼容性最好学校机房、个人电脑装的环境五花八门JDK 8 是最不容易出问题的。如果非要用 Spring Boot 3就得强迫所有人升到 JDK 17光这一项就能劝退一批人。持久层框架有两条路线MyBatis-Plus 和 Spring Data JPA。两者我各用过一段时间只做毕业设计的话我更推荐 MyBatis-Plus。原因是这框架的代码量省得非常可观单表CRUD完全不用自己写 SQL分页查询一行搞定而且 LambdaQueryWrapper 对新手阅读代码更友好。JPA 虽然也很强大但很多同学理解不了持久化上下文和懒加载一查数据就报毛病调试成本太高。数据库选 MySQL 8.0这是标配没什么争议。缓存组件引入 Redis用于车位状态缓存和分布式锁。这里我可以给一个小建议如果只是做单人毕设Redis 环境自己电脑装好就行但如果想在答辩现场展示“高并发解决”的思路Redis 是不可省略的环节。版本搭配我用实际组合做个参考组件版本说明JDK1.8稳定性优先Spring Boot2.7.182.x 最后一个稳定版MyBatis-Plus3.5.3含分页插件MySQL8.0.32InnoDB 引擎Redis6.2 以上缓存与锁Swagger/Knife4j4.x接口文档JWTjjwt 0.9.1无状态登录认证2.2 前端方案小程序还是Web后台前端方向的选择会直接影响整个项目的开发节奏。常见方案有微信小程序、Vue管理后台和 Thymeleaf 服务端渲染。我负责任地说如果是个人独立开发且时间有限最高效的组合是前端做两个端用户端用微信小程序管理端用 Vue Element Plus 的页面内嵌到项目里。但两者都做工作量不小需要取舍。更务实的降级方案是用户端用移动端适配的 H5 页面管理端用 Vue 独立项目。这样的好处是用户端和管理端复用了同一套 API后端开发专注逻辑前端用成熟的组件库快速搭建。Thymeleaf 服务端渲染的制作成本最低但页面效果确实一般答辩时视觉分容易吃亏。如果以前从没写过小程序我建议不要逞强。小程序从注册账号、审核类目到真机调试有一套独立的流程复杂度这些麻烦在临近答辩时会很折磨人。相比之下 H5 页面放到校园网络环境里直接浏览器访问效果一样能打。做毕设的核心思维是控制全流程中的不确定性而不是追求技术栈的时髦。2.3 数据库设计核心表结构剖析数据库设计是整个项目最值得花时间的地方。表结构设计得好后面写代码就是填逻辑设计得烂后面每写一个查询都像在补窟窿。我把核心表结构拿出来逐一分析。用户表保存账号信息和角色类型这里要注意的是用户和车辆是多对一关系一个用户可能绑定多辆车。车辆表之所以单独拆出来是为了配合车牌识别业务。当你设计停车场设备对接时进门摄像头扫到车牌系统要通过车牌反查用户信息这个字段天然是高频查询位必须加索引。车位表是最关键的一张表。字段不能只存一个“状态”我建议用状态字段加预约ID加锁定时间的组合来设计。车位状态至少包含空闲、占用、预约、锁定四种。有个很多初学者不会提前想到的场景线下保安叔叔手动把一个没预约的车放进了一个有预约的车位这种状况如果系统没有保留操作记录的能力业务就崩了。因此车位表里要冗余一个当前占用记录ID的字段方便追溯。预约表服务预约流程核心字段包括车位ID、用户ID、预约开始时间、入场截止时间、状态、订单号。计费需要订单表一个预约单对应一个停车订单入场时创建出场时计算费用。规范的做法是把预约和停车分为两张表用订单号关联因为实际业务里预约可能取消停车订单仍然独立存在。还有一张容易被忽略的是规则表。计费规则如果不配置而是写死在代码里那系统就废了。校园停车规则多样性决定了必须建一张规则表支持配置时段、车型、用户类型、计费单价和封顶金额。这样改收费策略不用动代码改配置就行答辩现场说“计费策略可配置”也是一句漂亮话。3. 核心功能怎么落地关键代码与业务逻辑3.1 车位实时状态与并发控制停车系统最怕的车位超卖问题。假设当前车位状态显示空闲两个用户同时提交预约请求如果代码只做“查询-判断-更新”三步操作数据库层面必然出现两个事务都读到空闲状态然后双双更新成功一个车位就约给了两个人。解决思路要从数据库层面下手。MySQL提供了悲观行锁机制在处理预约占位这种强一致场景下直接对车位行加锁是最直观可靠的方案。public synchronized boolean lockParkingSpace(Long spaceId, Long userId) { // 使用悲观锁查询时对车位行加写锁 ParkingSpace space parkingSpaceMapper.selectByIdForUpdate(spaceId); if (space null || !FREE.equals(space.getStatus())) { return false; } // 更新车位状态为锁定记录预约用户ID space.setStatus(LOCKED); space.setLockUserId(userId); space.setLockTime(new Date()); parkingSpaceMapper.updateById(space); return true; }上面的方法里selectByIdForUpdate 对应 MyBatis-Plus 自定义 SQL 中的 SELECT ... FOR UPDATE。这是数据库锁禁忌里最该学会的一个操作。只要注释掉 FOR UPDATE回表校验就形同虚设。事务边界也要格外注意锁定的生命周期必须包含整个业务逻辑。如果把 Transactional 加在 Service 层方法上方法运行期间持有数据库锁方法结束落库后锁才释放。这写法的好处是极端并发下也不出错代价是并发吞吐量降低。毕业设计场景下这种取舍完全没问题反而在答辩时可以清晰地说出自己如何解决线程安全问题。3.2 预约流程与锁的整合实现预约操作不是一个简单的状态更新它是一串连贯动作的组合查车位、创建预约单、锁定车位、更新用户预约数量。这串动作要么全部完成要么全部不生效。我把它们放进同一个事务里用 Spring 的声明式事务来控制。Transactional(rollbackFor Exception.class) public AppointOrder createAppointment(AppointmentDTO dto) { // 1. 锁定车位行 ParkingSpace space parkingSpaceMapper.selectByIdForUpdate(dto.getSpaceId()); if (space null || !FREE.equals(space.getStatus())) { throw new BusinessException(车位已被占用请重新选择); } // 2. 车位状态流转FREE - LOCKED space.setStatus(LOCKED); space.setLockTime(new Date()); parkingSpaceMapper.updateById(space); // 3. 创建预约单入场截止时间为当前时间 15分钟 AppointOrder order new AppointOrder(); String orderNo AP System.currentTimeMillis() RandomUtil.randomNumbers(4); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setSpaceId(dto.getSpaceId()); order.setStatus(WAIT_ENTRY); order.setEntryDeadline(new Date(System.currentTimeMillis() 15 * 60 * 1000)); appointOrderMapper.insert(order); // 4. 记录流水方便审计 SpaceOperateLog logRecord new SpaceOperateLog(); logRecord.setSpaceId(spaceId); logRecord.setOperateType(APPOINT); logRecord.setOrderNo(orderNo); spaceOperateLogMapper.insert(logRecord); return order; }注意一个关键点代码里的 15 分钟入场截止时间是写死的被我用了常量替代实际项目中建议从配置表读取。校园不同区域可能入场缓冲时长不一样比如说教学区地下车库一般提前 15 分钟截止而宿舍区可以放宽到 30 分钟。这个可配置往细节里做就可以在答辩报告中作为一个设计亮点。3.3 计费策略与结算引擎计费引擎是停车场系统里逻辑最有意思的部分。表面看是单价乘时长但真实的校园计费规则极其琐碎自由组合时很容易把代码写成 if-else 地狱。合理做法是把计费拆成两条线基础计价线负责计算时长相关费用附加策略线负责叠加用户身份、时段、减免等规则。public FeeResult calculateFee(ParkingOrder order, User user) { long minutes computeParkingMinutes(order); // 1. 基础费用按小时单价向上取整不足整小时按整小时计 FeeRule baseRule feeRuleMapper.selectBaseRule(order.getParkingLotId()); BigDecimal baseFee BigDecimal.valueOf(minutes) .divide(BigDecimal.valueOf(60), 0, RoundingMode.CEILING) .multiply(baseRule.getUnitPrice()); // 2. 优惠叠加教职工 8 折学生无折扣 if (TEACHER.equals(user.getRole())) { baseFee baseFee.multiply(new BigDecimal(0.8)); } // 3. 封顶校验单日最高 20 元超过则按封顶计 BigDecimal dailyCap feeRuleMapper.selectDailyCap(); if (baseFee.compareTo(dailyCap) 0) { baseFee dailyCap; } return new FeeResult(baseFee); }这些规则我看着简单放代码里也很短但实际落地时踩坑的地方全在细节。比方说“不足整小时按整小时计”的取整方式我见过好多同学用的普通四舍五入把一个小时的停车取整成了半小时对不上账单。这里的核心就是计算过程中必须注意 BigDecimal 的 scale 和 rounding mode不然你会被自己的账单数据折磨到崩溃。费用减免也不是简单扣一笔钱就完了还牵扯到费用减免的审批记录。谁减的、为什么减、减多少这些都必须留在表里。这部分的工程严谨性很可能成为答辩时老师问你的区别度。3.4 定时任务处理预约过期问题预约过期释放是毕业设计里必现的一个问题。用户预约了车位但有事没来这个车位要是一直锁着其他用户就完全没法用。解决思路是引入定时任务定期扫描超时未入场的预约并释放车位。Spring Boot 原生提供了 Scheduled 注解简单易用。在启动类上加上 EnableScheduling然后在服务类中配置一个每 30 秒执行一次的扫描任务。这里有一个工程上容易忽略但实际很重要的点定时任务在多节点部署时会重复执行如果同一个任务在多个实例上同时运行车位释放就会被重复处理。项目里我引入 ShedLock 来给定时任务加分布式锁这样多实例下任务只在一个节点上执行其他节点处于等待状态。虽然毕设场景基本是单机部署但把这个方案写进设计文档老师看到了会认为你具备分布式思维。另一个坑是任务启动时跑在了业务高峰前大量扫描任务并发执行把数据库索引没打好的表拖垮。优化思路是给预约表的入场截止时间字段加上精度合适的索引扫描 SQL 按时间范围限定避免全表扫描。4. 从坑到路接口设计规范与前后端联调的实践经验4.1 统一返回值与异常体系很多同学的代码里后端返回数据的格式五花八门。有时候返回 Map有时候返回 JSONObject有的查询成功返回 null有的又返回数组直接前端判断。前后端联调一半时间浪费在互相猜数据结构上这种体验极差。我落地这个项目时做的第一件事就是统一了一套返回规范。所有接口返回 R 对象包含 code、message、data 三个字段。code 为 0 表示业务成功其他为业务异常码。Getter public class RT { private Integer code; private String message; private T data; public static T RT ok(T data) { RT r new R(); r.code 0; r.message success; r.data data; return r; } public static T RT fail(Integer code, String message) { RT r new R(); r.code code; r.message message; return r; } }前端统一对 res.code 做判断不需要针对每个接口单独处理 errror 分支大大压缩了联调沟通成本。后端代码里所有业务异常都通过抛出 BusinessException 来标记配合 ControllerAdvice 全局异常处理器统一转成 R 对象返回。4.2 JWT认证与拦截器配置校园停车系统里有用户角色区分接口权限天然要分级。管理员接口和管理员页面对一般用户不能开放。我用 JWT 做无状态登录认证用户登录成功后后端签发 token前端每次请求在 header 里带上后端拦截器解析鉴权。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 )) { throw new BusinessException(401, 未登录); } Claims claims JwtUtil.parseToken(token.substring(7)); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } }这个拦截器主要做三件事解析 token、注入用户上下文、校验 token 状态。权限更高的角色判断我用独立注解完成比如 RequireRole(ADMIN) 加在方法上由另一个切面去校验角色字段。这块设计好之后后面所有接口只需要在需要管理员权限的地方加注解不用重复写 if 判断。4.3 联调中最容易翻车的细节前端联调阶段是我整个项目里踩坑最多的阶段。总结几个高频问题供大家避坑。跨域是首当其冲的问题。前端开发服务器跑在局域网某端口后端跑在另一端口直接发请求一定被 CORS 拦截。后端这里我用 WebMvcConfigurer 统一加入了跨域配置并且设置 allowedOriginPatterns 而不是 allowedOrigins。很多人用 allowedOrigins 配多个来源时发现怎么配都报错原因可能是 allowCredentials 与 allowedOrigins 规则在当前 Spring 版本中互斥需要改成 allowedOriginPatterns 来组合使用。第二个坑是时间格式化导致的时区偏移。后端返回的时间是 UTC 时间前端拿到后显示成了之前的时间计费记录看上去全错了。这个问题的根源是 Jackson 序列化时间时没有统一时区。我在 application.yml 里固定了时间格式和时区参数前后端统一用北京时区处理。第三个坑是 MyBatis-Plus 分页查询不生效。很多同学的代码里写了 Page 对象传进 selectPage 方法结果返回的数据还是全量。这个问题的根因是没注册 MyBatis-Plus 的分页插件。这个插件必须通过 MybatisPlusInterceptor Bean 显式配置文件不加分页插件Page 对象就形同虚设。这个坑我在别的项目里也遇见过印象非常深刻。这三个问题属于那种网上搜索可能一时半会儿找不到答案但在联调阶段又必然会遇上。提前写在代码注释里对将来的维护也是一种提醒。5. 从功能到亮点让项目不止于可运行5.1 低成本加分的三个进阶方向纯 CRUD 的停车系统答辩分数基本就在及格线上徘徊。想拉开差距不见得非得引入微服务或者各种重型框架价格又便宜效果又好的方向有三个。第一个是车位热力图。把每天各个时段的车位占用率统计出来用前端可视化组件渲染成热力图。这个功能背后对应的就是 SELECT 语句按小时 GROUP BY 统计再配合 Redis 缓存热点数据工作量不多答辩现场展示效果极好。第二个是车牌识别演示区。真实停车场品牌车辆识别设备动辄数万元毕设总不能真去采购。但简化版完全可以做成前端上传一张车牌照片后端调用图像处理库做车牌裁剪和字符识别或者模拟识别过程再把这个识别结果回传到系统。相比接入第三方 API 或 SDK这个自研演示方案既可控又有技术含量。第三个是消息通知。预约成功、预约超时释放、月卡即将到期这些业务节点通过模板消息推送提醒用户。校园环境下天然适合接入邮件或企业角度的消息推送。实在不想接邮件服务也可以在系统内部做一个站内通知模块效果一样有故事性。5.2 答辩准备时容易被问到的位置答辩老师提问通常集中在几个高频位置数据库表关系、并发解决方案、定时任务设计、接口安全。我建议把设计文档里面关于这几块的内容单独提炼出来做几张图业务流程图和 ER 图是必须有画出来的。画图的时候用朴素的连接线说明关系不要画乱。图其实比代码更容易建立沟通语境。还有一个小诀窍任何时候不要说自己“界面不好看”。答辩时如果主动说界面丑老师真的会一直盯着界面不放。应该把重心拉到业务闭环和技术细节上界面单纯属于锦上添花的维度。5.3 我对这套项目最真实的感受如果你准备做这个项目我的总体建议是功能宁缺毋滥核心链路的正确性必须保证。宁可少做一个报表也要把“预约-入场-出场-结算”这条主线走到无懈可击。这里说的无懈可击包括数据状态不会出错、重复请求不会生成两条订单、并发预约不会超卖。这三个问题如果有任何一个处理不到位功能再多也白搭。做这个项目之前我对车位状态的理解很朴素以为就是“空着”和“占用”两种状态。真正把预约、锁定、超时、取消这些环节串起来之后才发现状态机设计才是整个项目中最值得反复斟酌的地方。能把这套状态流转想明白哪怕毕业之后不做停车场相关开发这套建模方法论放在别的事务型系统里一样通用。最后再分享一个实际调试中的小场景当时测试预约流程我左边开着小程序模拟器右边开着数据库表每操作一步就刷新一次表数据。预约、入场、出场、结算这一路释义下来表数据在小心地跟着业务流转而变化。那一刻突然觉得系统确实是活的所有写的逻辑是在支撑一个真实世界可以落地的场景。这种从页面到数据完整闭环的感觉可能才是毕业设计给你最大的收获。
