每到毕业季，被选题卡住的人不在少数。java小区停车位管理系统这个方向，我见过不少同学拿了标题就发慌，其实它是我认为最适合Java方向毕设的题目之一：业务真实、边界清晰、工作量适中，论文、PPT、源代码、演示视频整套交付物都能围绕一条主线串起来，答辩时也容易讲清楚。更关键的是，这套系统的业务逻辑包含计费、状态流转、并发分配这些“有得聊”的点，比传统的增删改查系统更容易写出亮点。
这篇文章，我就按自己带过多轮这个题目的经验，把整套方案的拆解思路、技术栈选型、数据库设计、核心代码实现、论文写作、答辩准备和排坑经验全部过一遍。不管你是准备做这个题目，还是想参考一个完整的管理系统来套自己的选题，这篇内容都值得你从头到尾看完。
1. 毕业设计选题分析与技术栈搭配
1.1 为什么这个选题比传统的图书管理系统更好做
很多同学会把目光投向图书借阅、学生选课、员工考勤这类经典管理系统，原因很简单：网上的代码多，参考也多。但恰恰因为做的人多，这些题目的答辩通过率反而不高，老师一眼就能看出是模板改的，问两个业务细节就露馅。
小区停车位管理系统不一样。它的业务场景来自真实生活，每个小区都有停车位管理需求，老师一看就知道系统是做什么的，不用你花大段篇幅解释背景。同时它的核心业务链条足够清晰：车辆进场、占位、出场、计费、缴费、统计，这一串流程既有状态变化又有金额计算，做起来不会让人觉得是“玩具项目”。
更重要的是，这个题目有天然的扩展空间。你可以在基础功能之上加入月租包月、预约车位、车位锁控制、大屏统计展示、微信小程序端，这些扩展点每加一个，论文和答辩的素材就多一块。时间紧就做基础版，时间充裕就做增强版，项目天花板很高，能适配不同水平的学生。
从工作量角度看也合理。一个标准版包含三个端：后台管理端、门卫操作端、业主查询端，每端3到5个功能页面，数据库设计七八张表，核心代码量大概在3000到5000行之间。配合论文和演示材料，一个学期里按部就班推进是完全来得及的，不像部分题目看着简单实际做起来要命的复杂度。
1.2 Spring Boot + MyBatis-Plus + MySQL 技术方案确定
技术选型是这个项目里最不需要纠结的部分。直接给出结论：后端用Spring Boot 2.7.x，持久层用MyBatis-Plus，数据库用MySQL 5.7或8.0。这套组合在毕设领域里属于绝对的主流配置，资料多、报错容易搜到解决方案、答辩时老师也认可。
为什么具体推荐Spring Boot而不是SSH或Servlet原生开发？最直接的原因是Spring Boot把大量的配置自动化了，起步成本非常低。建一个工程就能跑起来，内置Tomcat不用单独部署，这对时间紧的毕设来说太重要了。而SSH那套文件配置和XML配置，光是环境调通就可能耗掉你一周时间，完全没必要在毕业设计里给自己添堵。
MyBatis-Plus是MyBatis的增强版，单表CRUD可以直接继承BaseMapper来完成，不用手写SQL，开发效率明显提升。我见过很多学生手写CRUD的时候一个字段写错排查半天，用MyBatis-Plus就能把精力省下来放到核心业务逻辑上。特别适合毕设这种以完成功能为第一目标的项目。
数据库选择MySQL是最稳妥的方案。5.7和8.0都可以，但我个人更推荐8.0，主要是字符集和性能上都比5.7省心。如果学校机房老版本用得多，5.7也完全够用，核心差别只有驱动依赖坐标里的mysql-connector-java要选对版本。这一点后面排坑章节会单独讲。
前端方面有两条路：一条是单体应用搭配Thymeleaf模板加Bootstrap，一条是前后端分离搭配Vue3和Element Plus。前者学习成本低，适合Java基础尚可但对前端不熟的同学；后者界面效果更现代，但需要额外处理跨域和联调问题。两条路线都能过答辩，关键看你自己哪边更熟。我的建议是：如果时间不超过一个月，优先考虑Thymeleaf，把精力留给后端业务；如果还有两三个月且对Vue有一定掌握，就大胆做分离式，视觉呈现比单体漂亮很多。
1.3 单体与前后端分离如何选择
我在辅导过程中最常被问到的就是单体还是前后端分离。这个问题没有绝对答案，但从答辩效果来看，两者各有侧重。
单体方案的好处是工程结构简单，一条项目跑起来就是全套，演示视频录制省时省力，部署也不需要单独配置Nginx。如果学校对系统外观要求不高，只要求功能完整，那我建议你直接做Thymeleaf单体，把精力放到逻辑层和数据库设计上。毕竟论文里写“前端使用Thymeleaf模板引擎渲染动态页面”没有任何问题，技术表达同样合理。
前后端分离的好处是界面好看，交互流畅，答辩展示时显得工程化程度高。同时你在论文里可以写“基于Vue3 + Element Plus构建响应式管理界面，通过RESTful API与后端交互”，这在大佬面前是有加分效果的。但是要花费额外精力处理跨域配置、Token鉴权、多个服务分别启动这些事，任何一个环节出错都会影响整体节奏。
有一种折中办法很适合犹豫的同学：后端做接口，前端用Vue2或者Vue3做单页应用，本地启动两个端口，开发时配置好跨越，部署时打包后由一个后端工程托管静态页面。这样既享受了前后端分离的视觉效果，又不至于部署太麻烦。我建议动手之前先把这两点想清楚，因为后期切换的成本不小。
2. 系统功能模块与数据库设计复盘
2.1 四类角色与功能模块边界
小区停车位管理系统的核心角色划分，我建议做三类：系统管理员、门卫操作员、业主用户。如果还想再加亮点，可以考虑一个超级管理员来管理普通管理员，不过这属于锦上添花，基础版不强制。
系统管理员负责系统的全局配置和统计工作。主要功能包括车位管理、费率规则设置、停车记录查询、营收统计、公告发布、人员账号管理。其中车位管理是最核心的模块，要支持车位的添加、编辑、删除、批量导入，还要能按区域、类型、状态筛选车位列表。
门卫操作员的角色要简单一些，就是针对车辆进出的快速操作。入场登记只需要输入车牌号，系统自动识别业主车辆还是临时车，然后分配空闲车位；出场登记输入车牌后自动计算停车时间和费用，收款后放行。这个角色是系统中使用频率最高的，必须设计得简单快速，页面上尽量一句话都不用多说就能操作。
业主用户端面向的是小区业主，功能包括绑定车辆、在线查看自己的停车记录、缴纳临时停车费、在线购买月租套餐。业主的数据与车辆、车位绑定，登录后看不到别人的信息。这个端是系统展示业务完整性的一部分，也是论文里写“多角色权限管理”这个点时的有力支撑。
权限控制实现上不建议做太复杂的RBAC模型，用一个角色字段加拦截器判断就行。Spring Boot里写一个HandlerInterceptor，根据Session中的登录用户角色判断是否能访问某个URL前缀，比如/manager/**只有管理员能访问，/guard/**只有门卫能访问，/owner/**只有业主能访问。这种方式清晰易懂，代码量不大，也能在论文里画权限控制流程。
2.2 数据库表结构与关键字段说明
数据库是整个系统设计中最需要花心思的部分。合理的表结构能保证数据不冗余、逻辑清晰、查询效率和扩展性都过得去。我按自己的实践经验整理了以下核心表，你可以直接参考。
业主用户表，主要存登录账号和基础资料。字段包括用户ID、用户名、密码、真实姓名、手机号、身份证号、角色类型、创建时间。密码必须加密存储，推荐使用BCrypt，这一点在论文里可以单独提一句“采用加密算法保障用户数据安全”作为亮点。
车辆信息表，记录业主名下车辆。字段包括车辆ID、业主ID、车牌号、车辆类型、品牌型号、颜色、创建时间。车牌号要加唯一索引防止重复绑定，同一业主可以绑定多辆车，一辆车也可以绑定给一个业主，一对多关系用外键字段owner_id关联即可。这里要注意一个细节，临时车不需要提前绑定，所以车辆表和业主表的关系是可选约束，允许owner_id为空。
车位信息表是系统最核心的表。字段包括车位ID、车位编号、所属区域、车位类型、当前状态、月租价格、备注。车位状态建议用int类型存，0代表空闲，1代表占用，2代表预约。这样设计的好处是后续如果需要扩展禁用车位、维修车位状态时，只需要加一个枚举值，不需要改表结构。车位编号是业务主键，要与门卫在页面上的输入体验一致，例如A区-101这种编码方式。
停车记录表是业务流水表。这个表的字段要完整但不要过度设计，重点包括记录ID、车牌号、车辆ID、车位ID、入场时间、出场时间、停车时长分钟数、应收金额、实收金额、支付状态、支付方式、操作员、创建时间。这里我建议把车牌号冗余存储一份，而不是只关联车辆ID，因为临时车没有车辆档案，出场结算时的流水要能查到当时的快照信息。
缴费充值表管月租套餐和临时缴费。字段包括订单ID、订单编号、业主ID、车牌、停车位ID、套餐类型、金额、开始时间、结束时间、支付状态、创建时间。用于支撑业主端在线购买月租、续费的功能。每个订单都应该生成唯一业务流水号，可以用时间戳加随机数的方式生成，格式建议为yyyyMMddHHmmss加6位随机数。
费率规则表是业务扩展的体现，很多同学容易漏掉。字段包括规则ID、规则名称、免费时长分钟、基础小时数、基础费用、超出每小时单价、单日封顶金额、状态。把计费规则做成配置化，比在代码里写死计费逻辑高级很多，论文里也可以讲“系统支持按需调整计费策略”。临时车计费和月租车续费都可以共用这张表。
核心表之间通过外键关联形成清晰的关系网，写论文画E-R图时也方便。车辆表通过owner_id关联用户表，停车记录表通过car_id关联车辆表、通过space_id关联车位表，缴费表通过owner_id和car_id关联用户车辆。主外键关系要清楚，但物理外键我建议不建，让逻辑层去保证数据完整性，这样删除数据时不用被外键约束卡住。
2.3 车位状态机与核心业务流转
车位状态是整个系统的心脏，理解它的流转，项目就通了百分之六十。系统的所有业务操作几乎都是围绕车位的状态变化展开的。
车位初始状态是空闲。车辆入场时，系统找到空闲车位并更新为占用。车辆出场时，系统更新记录结算费用，同时把车位释放回空闲。如果是月租车，入场时还要校验当前时间是否处于有效月租期内；过期未续费则按临时车计费。这条主链路就是状态机的全部节点转化，画一个状态流转表就是论文里的核心业务图。
预约占位是可选扩展模块。业主可以通过小程序或网页预约某个空闲车位，预约后车位状态变为预约，系统同时记录预约到期时间。如果超过预约时间没有到场，停车场的管理员可以手动取消预约，状态回空闲。这个功能需要新增预约订单表，同时定时任务轮询过期预约。有能力的同学做出来是很大的加分项，论文里可以写“引入定时调度框架完成预约超时自动释放逻辑”。
进出场流程是系统主流程，用文字描述清楚大概是这样一个闭环：
- 门卫在进入登记页输入车牌号，系统查询车辆信息。
- 车辆分类：该车牌绑定的车辆且月租有效，则为月租车；否则为临时车。
- 系统查询空闲车位列表，门卫选择车位或由系统自动分配空闲车位。
- 创建停车记录，记录入场时间，车位状态更新为占用，页面展示车牌、入场时间、车位号。
- 出场时输入车牌号，系统查找该车牌最近一条未出场的记录。
- 系统计算停车时长和费用，临时车按费率规则计价，月租车在有效期内费用为零。
- 门卫收款，支付状态更改为已支付，车位状态回空闲，出场时间写入记录，流水归档。
这套流程在实现时要注意一个边界情况：同一辆车可能连续多次进出，出场结算的时候必须定位到当前有效的那条入场记录，也就是入场时间不为空且出场时间为空且未删除的记录。很多学生在这个地方偷懒用车辆ID去匹配，结果出场记录全乱了，我们后面代码部分是演示逻辑的时候就专门讲这个。
3. 核心业务代码实现与难点突破
3.1 进出场登记的完整业务闭环
入场登记的核心逻辑不复杂，但要注意流程的完整性和事务性。我以门卫操作员输入车牌号开始写一段核心Service方法，展示如何处理入场流程。
@Transactional public ParkRecord entry(String plateNumber, Long spaceId) { // 1. 查车辆，判断是否包月车 CarInfo carInfo = carMapper.selectByPlateNumber(plateNumber); boolean isMonthly = false; if (carInfo != null) { PaymentOrder activeOrder = paymentOrderMapper.selectActiveByCarId(carInfo.getId()); isMonthly = activeOrder != null; } // 2. 锁定车位并更新状态 int rows = parkingSpaceMapper.lockAndOccupy(spaceId); if (rows == 0) { throw new BizException("车位已被占用，请刷新后重试"); } // 3. 创建停车记录 ParkRecord record = new ParkRecord(); record.setPlateNumber(plateNumber); record.setCarId(carInfo != null ? carInfo.getId() : null); record.setSpaceId(spaceId); record.setEntryTime(LocalDateTime.now()); record.setIsMonthly(isMonthly); record.setPayStatus("UNPAID"); parkRecordMapper.insert(record); return record; }这里有几个要点需要说明。第一步查车辆信息时，如果没有查到就保持carId为空，停车记录依然能创建，记录会进入临时车流程。第二步更新车位状态是关键，不能先查再更新，而是要直接用条件更新SQL去抢占车位，这个防并发方案下一节展开讲。整个方法加上事务注解，任何一个环节报错都要回滚，不能出现车辆入场了但车位状态没更新这种数据不一致问题。
出场时候的核心逻辑和入场对称。步骤是先找到当前有效的停车记录，然后计算时长和费用，再更新记录和车位状态。
@Transactional public BigDecimal exit(String plateNumber, Integer payType) { // 1. 查找当前有效记录 ParkRecord record = parkRecordMapper.selectCurrentUnExit(plateNumber); if (record == null) { throw new BizException("未找到该车牌的入场记录"); } LocalDateTime now = LocalDateTime.now(); long minutes = Duration.between(record.getEntryTime(), now).toMinutes(); record.setExitTime(now); record.setDurationMinutes(minutes); // 2. 计算费用 BigDecimal fee = chargeService.calculate(record.getEntryTime(), now, record.getIsMonthly()); record.setReceivableAmount(fee); record.setPaidAmount(fee); record.setPayStatus("PAID"); record.setPayType(payType); parkRecordMapper.updateById(record); // 3. 释放车位 parkingSpaceMapper.release(record.getSpaceId()); return fee; }两个方法组合起来就是进出场核心闭环。在实际项目中，你还需要在Controller层做参数校验，在页面层做交互反馈。这里给一个提醒：记录状态不要用删除来代表出场，而是用exitTime是否为空来判定，否则统计报表时历史数据会丢失。
3.2 停车计费规则的代码实现
计费逻辑是这套系统最容易被答辩老师追问的地方，也是最容易出bug的地方。常见的需求是有免费时长、按小时计费、不足一小时按一小时、每天封顶。我建议把计费逻辑单独抽一个ChargeService，输入入场时间、出场时间、是否月租车，输出应收金额。
public BigDecimal calculate(LocalDateTime entryTime, LocalDateTime exitTime, boolean isMonthly) { if (isMonthly) { return BigDecimal.ZERO; } FeeRule rule = feeRuleMapper.selectActiveRule(); long totalMinutes = Duration.between(entryTime, exitTime).toMinutes(); if (totalMinutes <= rule.getFreeMinutes()) { return BigDecimal.ZERO; } long billableMinutes = totalMinutes - rule.getFreeMinutes(); long billableHours = (billableMinutes + 59) / 60; BigDecimal fee = rule.getBaseFee(); long extraHours = Math.max(0, billableHours - rule.getBaseHours()); fee = fee.add(rule.getHourlyFee().multiply(BigDecimal.valueOf(extraHours))); if (rule.getDailyCap() != null && fee.compareTo(rule.getDailyCap()) > 0) { fee = rule.getDailyCap(); } return fee.setScale(2, RoundingMode.HALF_UP); }写代码时最容易犯的错误是直接用分钟数乘以单价再除以六十，这样会出现小数金额，和实际人工计算习惯不同。真实停车的计费习惯是“前15分钟免费，首小时5元，超过首小时后每小时3元，24小时内封顶30元”，按这种阶梯结构来拆解，代码和业务的对应关系就很清楚。我上面的示例就是先在规则表里定义免费时长、基础小时数、基础费用、每小时单价、单日封顶，然后按小时向上取整来算。
跨天场景必须仔细测。一辆车入场时间是昨晚23点，出场时间是第二天凌晨1点，停车时间2小时，数据库里的LocalDateTime处理没问题，但如果你用字符串直接相减，一定会出错。我在代码里统一使用LocalDateTime和Duration，就是为了避开跨天、跨月的时间计算坑，这个细节你可以直接写在论文的技术选型理由里。
3.3 车位并发分配的防重方案
并发问题是毕设项目里比较高级的加分项。场景就是多个保安同时操作，A窗口把车位12分配给了车牌A，B窗口同一时刻也要把车位12分配给车牌B，如果没有控制，就会造成一个车位被重复占用。
这个问题如果只在Service层用if判断状态再update，在高并发下依然可能出问题。因为两个请求都可能读到车位状态为空闲，然后先后执行更新。解决的办法是数据库层面的原子性更新。我推荐一个简单稳妥的方案，SQL里直接加上状态条件。
UPDATE parking_space SET status = 1 WHERE id = #{spaceId} AND status = 0配套的Mapper代码通过返回值判断更新是否成功，影响行数为0说明车位已经被人抢先占用了。这个方案在MySQL InnoDB引擎下是行锁级别的，同一时刻只有一个事务能更新这一行，另外的请求会阻塞或者失败。用这个方案的时候要把更新语句放在事务里，等待的请求也能正常拿到行锁后判断条件不再成立而返回0。
如果你在论文里写“通过乐观锁机制保证车位状态一致性”，这个方案完全站得住脚。有兴趣的同学还可以做悲观锁方案，SELECT ... FOR UPDATE，但代码复杂度会高，而且如果处理不好锁等待时间还会影响整个系统的吞吐量，不太建议在毕设阶段折腾太深。
3.4 营收统计报表的实现思路
报表模块是很多管理系统里必做的一个模块，停车位管理也不例外。最常用的几个统计维度是：按天统计进出车辆数和营收额、按月统计营收趋势、按车位统计占用率。造数据的时候你会体会到，报表模块把整个系统的数据价值体现出来了，也是PPT里最出效果的一个页面。
按天统计营收的SQL很简单，核心就是按入场日期分组聚合：
SELECT DATE(entry_time) AS bizDate, COUNT(*) AS carCount, SUM(paid_amount) AS totalFee FROM park_record WHERE exit_time IS NOT NULL AND pay_status = 'PAID' GROUP BY DATE(entry_time) ORDER BY bizDate DESC;车位占用率统计可以用“占用状态为1的车位数 / 总车位数”这个聚合指标，也可以在某个时间段内统计每个车位的平均占用时长，后者稍微复杂一点，涉及停车记录表按车位分组和时间差聚合。基础版做到前者就够用，扩展版再挑战后者。
前端页面展示推荐用ECharts，引入方式非常简单，用npm安装或者直接CDN加载都行，绘制折线图和柱状图的代码量也不大。我在实际项目里会把日报、月报、车位利用率放在同一个页面，顶部分三个Tab切换，观感很好，答辩演示时也能直观呈现系统的完整度。
4. 毕业论文写作结构与降重实操
4.1 论文目录结构与写作顺序
毕业论文写得像流水账是很多学生的通病，根源在于没有想清楚论文的叙事逻辑。停车位管理系统的论文我推荐按下面这条目录骨架展开，这也是国内高校计算机专业最常见的标准结构，通过率高且导师熟悉。
第一章绪论部分写课题背景、研究意义、国内外研究现状、主要工作内容；第二章写相关技术概述；第三章写系统需求分析，包括可行性分析、功能需求、非功能需求、用例分析；第四章写系统设计，包括整体架构、模块设计、数据库设计、接口设计；第五章写系统实现，按功能模块逐一贴核心代码和界面截图说明；第六章写系统测试，包括测试环境、测试用例和结果分析；第七章写总结与展望。
写作顺序建议不要从头到尾线性推进，而是先写需求分析和系统设计，因为这部分内容在系统开发前就已经构思好了。之后写系统实现，这个阶段代码已经写完，对着截图写说明非常快。最后再写绪论和总结，此时你对自己做了什么已经很清楚了，写作效率会明显更高。相关技术那一章反而最不用着急，可以放在最后凑内容。
每章的字数分配也要心中有数。本科毕设正文一般在8000到12000字左右，绪论大约1500字，相关技术1200字，需求分析2500字，系统设计3000字，系统实现3000字，测试1000字，总结500字。按这个比例分配，每章要写多少就很清晰，不会出现开头详细到啰嗦、后面草草收尾的尴尬。
4.2 图表、截图与参考文献的规范细节
论文里的图是导师愿意看的重点，因为图不容易造假，信息密度高。我建议你至少准备下面几类图：系统功能结构图、系统架构图、数据库E-R图、车位状态流转图、核心业务时序图、用户用例图、系统界面截图。其中E-R图和用例图是需求量分析的必备图，画得好能直接让论文整体档次上一个台阶。
画图工具方面，E-R图可以用draw.io或者ProcessOn，系统架构图用Visio，界面截图注意统一浏览器窗口大小，比如都用1920宽度的窗口，截图时把窗口缩小到一致比例，保证整套截图在论文里看起来整齐统一。截图里面不要出现无意义的数据和脏乱差的信息，演示数据要能支撑业务逻辑，比如停车记录里车牌和时间的对应关系别出现逻辑矛盾。
参考文献的数量和格式也是导师容易挑刺的地方。中文文献加英文文献建议一共20篇左右，时间尽量选最近三年到五年的，期刊优先于博客文章。JSP或SSH相关的旧文献就算了，容易被老师质疑技术落后。参考文献格式严格按照学校的模板要求来调整，注意期刊类文献要包括作者、题名、刊名、年份、卷期、页码，这个细节能看出你是否用心。
4.3 查重与降重的实操经验
查重最严重的区域是绪论和相关技术。主要原因是你写这些章节的时候容易参考网络资料，语句稍作大意的粘贴就会被红字标出。我的建议是尽量用自己的话把业务场景和技术理解描述出来，相关技术部分宁可写熟悉的内容多，也不要堆砌大段术语。老师更看重你对自己系统所用技术的解释能力，而不是论文里有多少专业名词的搬运。
降重技巧上，如果你某一段文字被标记了，不要健康替换几个关键词就提交，那样系统还是能识别出来。最有效的方案是把原文的长句拆成短句，把被动语态改成主动语态，调整句子顺序之后再做局部同义词替换，这样基本上能比较轻松地降下来。
很多同学容易忽略的是需求分析部分的用例描述、测试部分的测试用例表这些看起来“表格式”的内容，其实在知网系统里文本只要连续13个字符相同就会标红。我的经验是，表格内容也要用自己的话组织，不要直接复制教材原文。论文里引入自己系统的真实测试数据，既规避重复，又体现真实性。
5. 答辩PPT与演示视频制作指南
5.1 答辩PPT结构与节奏控制
毕业答辩的PPT不需要堆砌太多内容，一般控制在12到15页就够用。这个容量既能把事情讲完，又能保证听众不会犯困。整体结构我是这样安排的：封面页、目录页、研究背景与意义、系统需求分析、系统设计、数据库设计、系统实现界面展示、系统测试、总结与展望、致谢页。其中数据库设计和系统实现界面展示是重点，页面要多一些。
PPT的设计原则是文字精简，多用图表。每一页不要超过8行文字，标题用20到24号字，正文用16到18号字，关键词可以适当加粗。配色不要用花哨的渐变和渐变背景，简洁的纯色模板加统一的字体就足够。在系统实现页里，直接把做好的界面截图放上去，下面用一两句话点出该页面的核心功能，比大段文字讲解要直观得多。
答辩的节奏大约10分钟，PPT讲解时间控制在7到8分钟，留2到3分钟给老师提问。讲解时不要照着PPT读，而是要对每一页的核心点展开讲。比如数据库设计页不要只念表名，要讲“停车记录表是整个业务的核心，它记录了车辆从入场到出场状态变化的完整轨迹，并通过冗余车牌字段支持临时车扫码入场后的费用追溯”，这种表达才能体现你对自己的系统理解到位。
5.2 演示视频录制要点与脚本框架
演示视频作为交付物同样重要。很多学校的毕业设计最终需要录屏演示，甚至答辩时直接给评委看视频。录制工具推荐OBS Studio，免费开源稳定，码率画质都可调。输出格式选择MP4，分辨率至少1080p，帧率30就够，码率建议在8Mbps以上，这样画面里的文字不发糊。
演示视频的时长建议控制在10到15分钟，太短会让人觉得系统功能没讲全，太长老师也没耐心看。录制之前一定要写一个演示脚本，把每个步骤要操作什么、要说什么列出来。我给你的参考脚本流程是：视频开头展示系统登录页，输入管理员账号进入系统首页；接着演示车位管理，包括新增车位、编辑车位、修改车位状态；然后演示车辆入场登记，输入车牌后展示系统自动分配空闲车位；再演示出场结算，展示费用计算过程和车位释放效果；接着切换业主账号，演示绑定车辆和查询停车记录；最后回到管理员账号演示统计报表，展示柱状图和趋势数据。
录制环境要注意两点。一是背景干净，桌面图标清理掉，浏览器只保留需要的页面，录屏范围尽量只圈住浏览器窗口，别让无关弹窗飞进录屏里。二是声音录制要清楚，麦克风尽量靠近一些，环境噪音大的话可以后期用剪映降噪，音轨上有明显的忽大忽小声音会显得很不专业。配音不要念PPT文字，要用口语讲解每个操作在做什么、效果如何。
视频剪辑可以用剪映或者Premiere，剪掉录失败的操作片段，在转场处加上文字提示说明当前演示的是哪个模块。最后检查一遍全片有没有操作失误和语音口误，再导出最终版。如果用OBS直接录好没有失误的全程，也可以不剪辑直接提交，省时间又真实。
5.3 答辩高频问题与应答思路
答辩老师问的问题往往大同小异，核心就是为了验证两个事：系统是不是你自己做的，你能不能讲清楚每个决定背后的原因。这里把我整理的高频问题以及回答要点列出来，你可以逐条准备：
为什么选择这个题目？回答思路：结合小区停车难的真实生活场景，说明管理需求强烈，加上本人对Java开发的热爱，希望借助毕业设计系统提升工程实践能力。
系统的开发环境是什么？列举编程语言、开发框架、数据库、开发工具版本，回答时要求准确无误，这话基本是送分题，但答错版本号会显得不够用心。
数据库设计遵循了什么原则？回答范式化设计、主外键关联、避免数据冗余、关键查询字段添加索引。能举出停车记录表冗余车牌字段是“为查询效率做出的合理冗余”这个例子，就很出彩。
停车费用是如何计算的？把你的费率规则结合一个真实例子详细说明。比如入场10点，出场13点，免费15分钟，首小时5元，超出每小时3元，最后应交多少。这种计算题回答时必须口算准确，自己先提前验证。
如何处理多个操作员同时分配同一个车位？引用你的乐观锁条件更新方案，说明通过UPDATE ... WHERE status = 0让数据库保证并发安全。
月租过期会怎么样？说明月租到期后车辆出场按临时车收费规则计费，同时入口进入时系统也会提示月租已过期，建议业主及时续费。
系统安全性如何保障？先回答密码加密存储，再答拦截器做登录校验和角色权限控制，最后说数据库层面使用预编译SQL防止注入。这三点都能说出来就已经很完整了。
做了哪些测试？按功能测试、接口测试、兼容性测试三个角度展开，穿插测试用例表的数据说明测试覆盖情况。不要说没有测试环境，就老老实实描述本地测试过程即可。
这些问题的答案你都能提前准备，但我更建议你在准备过程中重新梳理一遍代码和数据库表，答辩的时候回答是自然而然说出的，而不是背稿子背出来的。
6. 常见问题与答辩防翻车排坑实录
6.1 环境配置类翻车现场
环境配置阶段是最容易耗时间的坑，我总结几个高频问题和解决方案。
JDK版本与Spring Boot版本不匹配。Spring Boot 2.7.x兼容Java 8到Java 17，如果你用的是Spring Boot 3.x，那JDK最低要求是17，很多同学用的还是8，一启动就报错。选型时直接固定Spring Boot 2.7.18加JDK 8这个组合，按教程配置完全不会踩坑。Lombok版本也是一样的，JDK 8配Lombok 1.18.24，JDK 17配更新的版本，如果版本偏低会出现编译时找不到getter和setter的报错。
Maven依赖下载失败或特别慢。这是国内网络环境绕不开的问题。解决办法是在Maven的settings.xml里配置阿里云镜像仓库，配置完成后重新reload项目。这个操作非常简单，但能瞬间把下载速度从几十KB提速到几MB，基本不会再有依赖下载失败的烦恼。如果你在学校的旧电脑上开发，还可以考虑直接把url配置成公司内网镜像，但最常见的还是阿里云。
MySQL连接不上或者乱码。连接不上优先检查MySQL服务是否启动，Windows下在服务管理里看MySQL服务状态；然后检查端口是否为3306，如果本地装了多个数据库版本，端口可能被占。乱码问题的根源是连接字符串没有指定编码，在JDBC的url后面加上useUnicode=true&characterEncoding=utf8基本能解决，注意别把连接串里原有的参数覆盖掉。
6.2 功能实现与联调阶段的问题
开发过程中问题就更多了，这里挑影响面最大的几个来说。
时间计算出错是重灾区。入出场记录里的LocalDateTime类型需要前端统一格式转换，如果你直接把LocalDateTime返回给前端，默认会输出一个带T的中间格式，页面显示很难看。最简单的方式是用Jackson的全局配置，在yml里配置spring.jackson.date-format统一格式，或者字段上添加@JsonFormat注解。更推荐后者，因为对单个字段的格式控制更灵活。
伪造的数据不统一。很多同学为了演示效果直接在数据库里手工插入大量数据，结果费率和车位状态对不上。数据库里造数据的部分要遵循业务逻辑，比如要统计营收就要保证停车的入场时间和出场时间相差至少一个小时，支付状态是已支付。演示之前把整个流程走一遍，从入场到出场再到统计图表，确保数据链是通的。
跨域问题在前后端分离项目中几乎必现。开发阶段后端在8080端口，前端在5173端口，前端请求后端需要后端配置CORS。Spring Boot里写一个CorsFilter配置类，放行前端页面所在路径即可。如果用了Spring Security，还需要把预检OPTIONS请求也放行，这个细节容易卡住很多同学。
6.3 答辩现场防翻车清单
答辩现场翻车大多是环境问题造成的，不是代码问题。提前准备一个检查清单非常有用，我建议你在答辩前一个晚上按这个顺序全部过一遍。
数据库服务必须启动，数据库文件所在位置和密码都写清楚贴在电脑屏幕上或备忘里。启动后端项目前，确认端口没有被其他进程占用，可以用netstat命令查看。启动后先调一下/login接口，确认请求能通，再打开前端页面。演示数据不要裸奔，准备一份干净的备份SQL，在答辩前一晚重新导入一遍，把演示数据恢复到整齐的初始状态，避免乱七八糟的历史数据削弱演示效果。
备用方案也要准备一手。把演示视频文件放在桌面，万一现场网络或者系统环境调试不出来，可以直接播放视频。如果现场没有外接显示器，提前把系统页面分辨率调整为适合投影的尺寸。答辩当天带一个U盘备份好项目文件夹、SQL脚本、论文PDF、PPT和演示视频，这个习惯能应对很多突发情况。
7. 一些个人的经验和建议
这套系统我带过不少轮，最大的体会是：毕业设计不追求功能越花哨越好，而是追求主链路稳定、讲解顺畅、论文结构完整。把基础功能和核心难点做好，在答辩时做到对业务逻辑了如指掌，比堆一堆运行不稳定的扩展功能要强得多。如果时间不够，先保证主流程能跑通，真的，这是最宝贵的经验。
计费规则和并发控制这两个点是能让你区别于普通增删改查系统的关键。哪怕是简化版的实现，哪怕只有五六行核心代码，也要确保自己能把这个逻辑讲清楚。深度比广度重要，这一条在任何答辩场景里都适用。
最后分享一个提升安全感的小技巧：答辩前找同学扮演评委，对你连续发问十分钟，尤其是计费计算题和数据库设计理由，被问住的地方就是你回家后要补的功课。把自己的系统从里到外都想透，这个项目才算真正做完。
