1. 先搞清楚选题：停车场管理系统到底在解决谁的什么问题
先说个实在话，SpringBoot停车场管理系统这类毕业设计题目，在每年的选题库里几乎都不会缺席。很多同学第一眼看到觉得"不就是个增删改查吗"，心里先给它降了档，结果真做起来才发现，光是一个"车位被占用时正好有人下单预约"的并发问题就够折腾好几天的。它表面上是管理信息系统的活儿，实际上牵扯到角色权限、订单状态机、计费策略、并发控制、报表统计，是一个麻雀虽小五脏俱全的web项目。
这个课题的核心价值，不在于你用了多新的技术，而在于你能不能把一条"车辆入场—车位分配—计时计费—缴费离场"的完整链路讲清楚、做扎实。基于SpringBoot框架来实现，意味着你的后端可以快速组织出清晰的模块边界，配合MySQL做数据持久化，再配上管理端页面，就是一个能演示、能答辩、能讲出设计思路的完整作品。所以这篇内容适合所有正在选课题或者已经选了智慧停车方向的同学，也适合想用一个中等复杂度项目练手SpringBoot全流程的开发者。
我之前见过不少同学在开题报告里把"智慧停车""智能车库"写得天花乱坠，好像要做出来一个能实时调度车位、自动识别车牌、无人值守的工业级系统。可实际动手，连最基本的"临时车按小时计费"都算不对。问题就出在需求阶段没有把系统的边界划清楚。你选的若是毕业设计，重点从来不是"智能"听了多高级，而是你能不能把业务闭环的每一步用代码和数据库表严谨地支撑起来。
1.1 三种角色一条线：管理员、车场操作员、车主的诉求各不相同
一套合格的停车场管理系统，至少要服务三类人。第一类是系统管理员，他要维护车场的车位信息、计费规则、用户账号，还要看每天的营收和车流量报表。第二类是车场操作员，他可能是门岗、地库管理人员，负责处理车辆的入场登记、出场结算，以及一些异常情况比如车牌识别失败、临时车没带卡等。第三类就是车主，如果系统带预约和缴费功能，车主可以在手机端查车位、预约、缴费、查看历史订单。
很多人做这类系统时容易犯一个错，就是只考虑管理员的视角，后台能增删改查就算完事。结果答辩的时候评委问一句"车主端和后台的数据是怎么关联的"，直接卡壳。实际上这三类角色的诉求是一条业务链路的三段：车主产生停车行为，操作员完成入场出场的登记动作，管理员在后头看全盘数据。你的用户表、角色表、权限控制，都得围绕这条链来设计。
我在带项目时，习惯先把一张"角色—功能—页面"的对应表画出来。管理员对应车位管理、费率设置、统计报表；操作员对应车辆入场、出场登记、异常处理；车主对应找车位、预约、缴费。这张表定下来，再去做后端接口设计，才不会东一榔头西一棒子。
1.2 核心流程：从车辆入场到计费离场，整条链路怎么闭环
这套系统最核心的流程其实就是一条线：车到场，生成一条停车记录，记录入场时间；车离场，根据计费规则算出费用，生成订单；支付完成后，车位释放，记录出场时间。听起来简单，但每个节点都有分支。
以临时车为例：车辆到达停车场入口，系统找到一个空闲车位，把该车位状态置为占用，同时生成一条停车记录，记录入场时间。此时车辆离场时，操作员在系统里选择该车辆，系统根据停车时长和计费规则计算金额，完成收费后，更新停车记录的离场时间，把车位状态改回空闲，整个流程闭环。
但实际业务里还有月卡车辆，月卡用户不需要每次缴费，他的订单状态可以直接标记为"月卡抵扣"或者没有金额。还有预约车辆，车主提前在系统里预约一个车位，系统要为这个车位做"预占"或者"锁定"，又是一种状态。所以，这块业务建模做得好不好，直接决定你后面代码是"写起来顺手"还是"天天打补丁"。
2. 业务建模：角色权限、车位状态与停车链路的设计思路
很多同学拿到这个题目后，第一反应是翻数据库设计资料，找现成的表结构。这个思路本身没错，但直接抄表结构是最容易出事的。因为你不知道别人那套表结构适合什么业务场景，盲目照搬，等做到计费功能发现字段不够用，再回头改表，那才叫痛苦。我的建议是，先自己想清楚业务，再对着需求设计表，最后才去参考别人的设计查漏补缺。
2.1 用户、角色、权限：SpringBoot里怎么做授权控制
既然定了三种角色，用户模块就不能只放一张user表了事。常规做法是有两张基础表加一张关联表：用户表、角色表、用户角色关联表。权限的控制我建议用SpringBoot的拦截器配合自定义注解来做，而不是引入一套完整的Spring Security体系。原因很现实：毕业设计的时间有限，Spring Security的配置链、过滤链、密码加密组件，光是配通就要消耗不少精力，而且答辩的时候如果你讲不清楚Security内部机制，反而容易成为短板。
自定义注解加拦截器的方案实现起来非常直观：定义一个@RequireRole注解，标注在接口方法上；再写一个拦截器，在进入接口前校验当前登录用户是否拥有对应角色。这样的设计在论文里也好写：基于AOP思想实现的轻量级权限控制，简单清晰。当然，如果你的项目定位是"能跑通、能演示"，JWT做登录态管理，加上这个拦截器方案，已经足够稳妥。
token这块，实践里我推荐把token存到Redis里，设置过期时间。为什么不用无状态JWT硬扛？因为如果用户权限变了、账号被禁用、或者需要强制下线，无状态JWT很难即时失效。而Redis里存一份token，登录时写入，登出时删除，拦截器里先查Redis再放行，逻辑非常直白，答辩时还能顺势讲一讲"会话在线管理"的设计思路。
2.2 车位状态不能只有"空闲"和"占用"
这是整个数据库设计里最容易被低估的一张表。很多初版设计里，parking_space表就两个字段：车位编号area_no和状态status，status用0表示空闲、1表示占用。等做到预约功能，你发现车位还需要"预约锁定"状态；做到故障报修了，车位还得支持"不可用"状态。到那时候再回头改枚举，牵扯的是所有已经写完的查询语句。
所以定义车位状态时，我建议一开始就留出四到五个状态：空闲、占用、预约锁定、不可用，另外还可以加一个"待保洁维护"之类的扩展状态。每个状态在系统里对应一种可执行操作：空闲才能被入场分配或被预约；占用状态下只能等出场结算后才能释放；预约锁定状态可以设置一个超时时间，超时未到场自动释放；不可用状态在后台手动管理，比如车位损坏、施工占用。
我当时做模拟项目X的时候，就是因为状态枚举一开始只写了两个，做到预约模块直接返工，连跨了三天。这是很典型的前期建模偷懒、后期加倍偿还的案例。
2.3 停车记录与订单分开建表：为什么不能混在一张表里
还有一张关键表是停车记录，有的同学会直接叫order表，把入场时间和缴费金额全塞进去。这种做法在演示阶段看不出问题，但你算报表的时候会发现，查"今日停车总次数"和查"今日营收总额"居然是同一张表，逻辑上很别扭。
更合理的方案是分开：停车记录表记录每一次车辆停放行为的起止时间、车位号、入场方式；订单表记录这笔停车行为对应的支付信息，应付金额、实付金额、支付时间。两者用一次停车记录的主键关联。为什么这么拆？因为一次停车行为在没有离场之前，根本不存在订单；可能有入场记录，但没有费用。而一个订单只有一条停车记录对应，这种1对1关系用外键关联非常清晰。
订单如果还涉及月卡用户，它对应的金额可能是0，但状态和缴费时间仍然要记录。这套设计在写统计SQL的时候特别顺手，按"支付时间"去聚合订单表，按"入场时间"聚合停车记录表，数据口径完全不会打架。
3. 数据库设计：计费规则独立建表，才是这套系统的灵魂
说完业务建模，必须单独把计费规则拎出来聊。因为停车场系统的业务复杂度，一半都藏在计费规则里。很多同学把费率写成代码里的常量，首小时多少钱、之后每半小时多少钱，直接用魔法数字写在Java类里。演示是没问题，但答辩被问到"如果停车场要调整收费标准怎么办"，答不上来。计费规则必须数据化。
3.1 费率结构设计：梯度、封顶、跨天都不能写死在代码里
设计一张计费规则表，最基本的字段是：规则名称、车辆类型、单位时间、单价、免费时长、封顶金额。比如某停车场临时车的规则是：进场首小时免费，超过1小时后每30分钟收费2元，24小时封顶20元，就需要在表里能表达出这个逻辑来。
这里有一个常见的难点：跨天计费。如果你只算"停车总时长×单价"，某辆车停了三夜，费用会非常离谱。所以计费引擎里要按自然日做分段计算，每达到一个24小时周期就用封顶金额，剩余不足一天的部分按正常梯度算。这块逻辑建议封装成一个独立的计费服务类，输入停车时长和车辆类型，输出金额。单元测试就盯住几个边界场景：刚好1小时、1小时零1分钟、23小时59分、24小时整、跨了3天零2小时。
3.2 数据库表结构：从用户到报表一共需要哪几张核心表
我把这套系统的核心表结构梳理一遍，你们可以作为参考，但不建议原样照抄，最好是根据自己选定的业务范围做增删。用户表、角色表、用户角色关联表算一组；车位表、车辆信息表、停车记录表算第二组；订单表、计费规则表算第三组；如果带预约功能，再加预约表；带月卡功能，加月卡表；最后如果要做公告管理，加一张公告表也足够了。
拿停车记录表举例，比较完整的字段是：主键、车位编号、车牌号、车辆类型、入场时间、出场时间、入场操作员、出场操作员、入场方式（手动/自动）、订单编号。这套字段跑出来的报表就能回答很多业务问题了：今天哪个车位周转率最高？哪个时段是入场高峰？平均停车时长是多少？答辩时能拿出这些分析数据，比空讲"系统功能完备"有说服力得多。
3.3 订单状态机：待支付、已支付、已退款、已关闭
订单表建议设立一个status状态字段，我建议至少包含：待支付、已支付、已退款、已关闭。待支付说明车辆已经离场但费用没付进去，比如部分支持先离场后缴费的场景。已支付就是正常完成缴费。已退款用于处理重复支付、误收费等异常。已关闭就是超过支付时限，系统自动取消订单，这种情况怎么处理？如果车主一直不缴费，订单超过一定时间就要有对应的处置流程。
对于毕业设计来说，把状态机画出来是一张很好的答辩素材图。我当时做这个模块时，把状态流转规则写成了注释放在service层类顶部，既方便自己写代码，也方便答辩时对着代码讲"我是如何控制状态不跳变的"。评委看到你能把状态机讲成闭环，印象分会高不少。
4. SpringBoot落地：鉴权、并发、计费这些模块怎么避免翻车
表设计得再好，到了SpringBoot代码落地环节，该翻的车还是会翻。这一块我挑几个最容易出问题、也最能体现你项目含金量的模块来讲。注意，这里讲的是设计思路和避坑要点，不是完整代码，因为每个人表结构不一样，代码直接抄是跑不通的，关键是理解为什么这样做。
4.1 登录鉴权的落地细节：拦截器、Redis和自定义注解怎么配合
登录接口的逻辑非常简单：接收用户名密码，校验通过后生成一个随机token，存Redis，设置过期时间，同时把用户信息返回给前端。前端后续请求在请求头里带上token，后端拦截器先校验token是否存在并且有效，再把用户信息塞到ThreadLocal或者请求上下文里，方便后续业务代码直接获取当前操作人。
我要特别提醒一个新手容易踩的坑：Redis的过期时间是倒计时式的，也就是说用户只要一直在操作，token到了时间还是会失效，体验很差。解决办法是"滑动过期时间"，每次请求进来，如果token有效就重新设置过期时间，这样只有用户连续一段时间不操作才会被踢下线。这个细节在答辩里讲出来，妥妥是加分项。
权限控制方面，拦截器里拿到用户角色后，再对照接口上要求的角色注解做判断。比如车位管理接口要求管理员角色，入场登记接口要求操作员角色。判断不通过就返回统一的"无权限"响应，不要在前端写死隐藏按钮，那只是体验层优化，不是权限控制。
4.2 车位占用问题的并发处理：为什么要在一次更新里完成校验
这是整套系统里最值得写进论文的技术难点。场景是这样的：两个车主同时预约同一个空闲车位，A请求和B请求都查到了车位空闲，然后都执行预约插入，结果就是同一个车位被预约两次。要处理这种并发问题，有几种方案。
第一是数据库层面的乐观锁，就是在车位表加一个version字段，更新时带上version条件，UPDATE ... SET status=1, version=version+1 WHERE id=? AND status=0 AND version=?，如果影响行数为0，说明有人在之前抢先改掉了状态，当前请求就按失败处理。这招简单有效，而且是SQL层面保证原子性，不需要额外引入中间件。
第二是Redis分布式锁，先在Redis里设置一个"lock:车位ID"的锁，拿到锁的业务代码再做查询和更新。这个方案在单体应用里做有点杀鸡用牛刀，而且锁超时时间的设置本身有讲究，时间设短了业务没执行完锁就过期，设长了万一服务宕机又得等锁自然过期。所以对于毕业设计，乐观锁方案更合适，理由也更好讲：避免引入不必要的复杂组件。
4.3 计费引擎：把时间参数和运算逻辑分离，才能讲清楚
计费这一块，我强烈建议单独写一个FeeCalculator类，不要和订单Service混在一起。它的输入是计费规则对象、车辆类型、入场时间和出场时间，输出是总费用。内部的算法要点我在前面讲跨天计费时提过，这里再补充一个边界：免费时长的处理。比如规则是15分钟内免费，那计费时长要先减去免费时长再计算，如果减完小于等于零就不计费。
要注意，入场和离场时间存储在数据库里，建议统一用LocalDateTime而不是Date。LocalDateTime配合MyBatis-Plus的自动填充功能，插入时自动填入场时间，更新时自动填出场时间，代码层面可以减少很多重复赋值。这个功能很多人会用，但答辩时能讲清楚"自动填充解决了什么问题"的，说明真的自己动手写过。
4.4 全局统一返回与异常处理：接口风格的加分项
SpringBoot接口返回结构建议统一，比如返回Result对象，里面包括code、message、data三个字段。成功返回200，业务异常返回4xx或者自定义业务错误码，系统异常统一500。配合@RestControllerAdvice做全局异常捕获，好处很明显：不是每个接口都要写try-catch，代码干净，前端处理响应也统一。
全局异常处理器里，业务异常类要自己定义，比如参数校验失败、车位不可预约、车辆已在场内等，每个异常都给一个明确的错误码和中文提示。这样做的好处是，答辩演示的时候，你故意触发一个异常，页面上弹出的是你定义好的提示信息而不是一堆堆栈日志，评委一看就知道这个项目是真做过异常处理的，不是靠运气跑通。
5. 把面做全：车牌识别模拟、管理端页面与统计数据
很多同学做完后端接口就觉得大功告成，但毕业设计的完整度还体现在前端能不能把功能串起来。前端不需要做得多华丽，但要能覆盖核心操作链路，别让评委看到你在Postman里点接口之类的情况。
5.1 车牌识别模块：没有真实硬件也不用慌
真实的停车场系统会对接车牌识别摄像头，车辆进场时摄像头拍到车牌号，通过接口传给你后端。但做毕业设计，大部分同学手头没有硬件，这时候需要做一个模拟方案。
我建议在后端留一个车牌识别接口的对接层，同时提供一个模拟入口。实际操作是：操作员在管理端页面手工选择或输入车牌号，甚至可以从一批预设车牌里随机选一个，模拟"识别到一辆车进场"。后端代码里写一个车牌识别适配器接口，真实场景下对接摄像头SDK，演示场景下返回模拟车牌。这个设计的好处是，论文里你可以写"系统预留了车牌识别硬件的扩展接口，目前通过模拟数据完成联调"，非常稳妥，评委也挑不出毛病。
5.2 管理端核心页面：车位可视化与在场车辆列表
管理端首页我建议放一个车位分布图，用网格展示每个车位，不同状态用不同颜色区分，空闲是绿色、占用是红色、预约锁定是黄色、不可用是灰色。这个页面视觉效果直接，能让人一眼看出系统的实时运作状态。旁边再配一个"在场车辆"列表，展示每辆车的入场时间、车位号、车牌和停车时长。
出场结算页面是操作员使用频率最高的页面，输入车牌号查询停车记录，系统自动展示应收费用，操作员点击确认收款后，状态流转为已支付并释放车位。整个链路上每一个页面都有明确的任务，页面之间不能跳来跳去，要顺着业务操作流来组织导航。
5.3 统计报表：让系统会"说话"的数据洞察
报表模块是区分"会做系统"和"会做产品"的分水岭。我建议至少做三张统计图表：今日营收趋势折线图、车流量分时柱状图、车位周转率排行榜。数据来源都是前面那几张核心表。营收趋势按订单表的支付时间聚合，分时车流量按停车记录的入场时间聚合，周转率则需要做一次分组计算——统计每个车位在一天内被占用的次数。
图表库可以用ECharts，后端提供聚合接口返回JSON，前端渲染出图。这块功能不难，但它让你的系统从"记录工具"变成了"辅助决策工具"，在论文里可以大大方方地写"系统提供运营数据可视化分析，支持停车场管理者掌握实时运营状态"。答辩效果比千篇一律的增删改查强多了。
6. 论文和答辩：真正的加分项是问题分析和对比论证
最后说论文和答辩。很多同学论文写得像用户手册，大篇幅贴界面截图，然后写这功能怎么操作。这在答辩委员会眼里是最没含金量的写法。论文里真正该突出的是"你怎么分析和解决技术问题"。
6.1 需求分析与可行性：图表比文字更有说服力
需求分析章节，建议多用用例图和用例说明书。每个角色每个核心功能，写清楚前置条件、主流程、异常流程。比如"预约车位"这个用例，主流程是车主选择车位、确认预约、系统锁定车位；异常分支是预约超时未到场，系统自动释放车位。把这些用例梳理完，你后面写代码其实就有了导航图，不会做着做着忘了一块逻辑。
技术可行性分析里，除了写SpringBoot具备生态成熟、开发高效等特点，也可以简单对比一下其他框架，比如传统SpringMVC。讲一下为什么选SpringBoot而不是SpringMVC，理由可以落在自动配置、简化部署、内嵌容器、大量starter支持这几个实际优势上。不用长篇大论，但这段对比会让评委觉得你选型是思考过的。
6.2 核心难点怎么讲：不要回避并发和状态管理
答辩时被问得最多的问题，大概率集中在"如果两个人同时预约同一个车位怎么办""如果车一直不出场怎么计费""月卡和临时车同时抢一个车位怎么处理"。这些问题都是这套系统真正难的部分，也正是你前面做好的表设计和代码逻辑应该能回答上来的。
我的建议是，答辩讲解顺序不要从页面开始，而要从"一条车辆从入场到出场的完整流程"讲起，边讲边指出在每个环节你是如何设计数据表和状态控制逻辑的。只要你能清楚讲出：入场时车位状态怎么校验、离场时费用怎么计算、同时请求时数据库如何保证不冲突，整个答辩就已经站在安全线之上了。
6.3 测试数据与演示脚本：提前准备一套不会被问倒的数据
有一个非常容易被忽视的环节是测试数据。很多同学现场演示时，库里只有三五条记录还都是散乱的，演示个报表发现曲线是平的。建议你写一套数据生成脚本，用循环生成过去30天的停车记录和订单记录，金额分布、入场时段分布都要符合常识。比如工作日早晚高峰入场多，周末下午入场多，夜间长时间停车费用偏高。
另外一定要准备一份演示脚本，按正常业务顺序走一遍：月卡用户入场、临时车入场、预约车辆进场、车辆离场缴费、查看报表数据变化。走完这套流程，评委对系统业务闭环的认知就成形了。写完这套系统之后，我自己最大的体会是：SpringBoot项目能不能做好，技术本身反而是次要的，真正的分水岭在于你对业务问题的理解深度和建模能力。一个停车场从门口抬杆到手机缴费，背后是一整套状态、规则和数据的精密配合。把这条链想透了，写出来的代码才称得上是一个系统，而不是几张表的堆砌。
