每年到这个时间点，都会有大量计算机专业的同学开始头疼毕业设计选什么题目。在Java Web这个方向里，停车场管理系统几乎可以算是经久不衰的经典选题，但正因为做的人多，想做出差异化反而更难。如果你手里现在拿到的标题是“基于SpringBoot框架的智能车库运营平台”或者“智慧停车服务系统”，那恭喜你，选对方向了——这个题目工作量适中、技术栈主流、演示效果直观，而且只要把几个核心模块做扎实，答辩时完全有东西可讲。

这篇文章我不会跟你扯那些华而不实的概念，直接从实际开发的角度拆解这个项目：核心功能怎么设计、数据库表怎么建、计费流程怎么实现、哪些地方容易踩坑、答辩时老师最爱问什么。无论你是打算自己从零写，还是参考别人的项目改造，这篇内容都能让你少走不少弯路。

1. 项目整体拆解：停车场管理系统到底在解决什么问题

1.1 核心需求解析

先想明白一件事：停车场管理系统本质上是干什么的？说得直白一点，它就是把“车辆进入停车场、找到车位停好、离开时计算费用并缴费”这一系列线下行为，搬到线上进行信息化管理。但如果你只做到这个程度，那这个项目就太单薄了，撑不起“智能车库运营平台”这个title。

一个能拿得出手的停车场管理系统，至少要覆盖三个角色的诉求：

车主端：查询剩余车位、快速入场、自助缴费、查看停车记录。现实中很多停车场已经做到车牌识别自动抬杆，但作为毕业设计，你可以用“手动录入车牌+系统分配车位”的方式模拟这个过程。

管理员端：车位实时监控、入场/出场登记、收费规则配置、订单管理、异常处理（比如某个车位被占用但系统没记录）。这部分是整个系统的管理核心，也是你展示CRUD功底的舞台。

系统层面：计费规则要灵活可配（按时长、按次数、免费时段、封顶价格）、数据要可视化（今日车流量、当前占用率、营收统计）、操作要有日志记录。

别小看这个需求拆解，很多同学上来就建表写代码，做到一半才发现字段不够用、流程对不上，返工成本极高。我的建议是：动工之前，先把这三个角色的核心操作画成流程图，哪怕是用纸笔草草画一下，都能帮你避开大量逻辑漏洞。

1.2 为什么选SpringBoot而不是其他框架

这个题目用SpringBoot几乎是标准答案，但你得知道为什么，答辩时老师一定会问。SpringBoot的核心价值在于“约定大于配置”——传统的SSH或SSM框架，光配置文件就要写一大堆，SpringBoot把大部分自动配置都封装好了，让你把精力集中在业务代码上。

对比其他方案也很直观：如果只用Servlet/JSP，开发效率太低，而且代码耦合严重，难以体现分层思想；如果选Python的Django/Flask，虽然开发快，但作为一个计算机专业的毕业设计，Java技术栈在展现“工程化能力”方面更占优势；SpringCloud那套微服务架构对这个规模的系统又属于杀鸡用牛刀，徒增复杂度。

SpringBoot恰好处于“够用且主流”的甜蜜点：上手门槛不高、社区资料丰富（这意味着你遇到问题几乎都能搜到答案）、企业实际需求量大（现在很多中小公司的后台系统就是SpringBoot+MyBatis这套组合拳）。一句话总结：选SpringBoot不是因为它最先进，而是因为它最适合这个体量的项目，而且最能体现你的工程素养。

2. 技术架构与核心设计思路

2.1 分层架构与技术栈选型

系统整体采用经典的前后端分离架构，技术栈如下：

后端：Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.0 + Redis（可选）+ Sa-Token（或JWT）做登录鉴权

前端：Vue 3 + Element-Plus + Axios（管理端后台），如果你不熟悉前端开发，也可以直接用Thymeleaf模板引擎做服务端渲染，工作量更少但视觉上会朴素一些

工具：Maven管理依赖、Git做版本控制、Postman测接口（或者用Apifox，国产工具更顺手）

说到技术选型，我得专门聊两句MyBatis-Plus。很多教材还在教MyBatis写XML映射文件，但实际开发中MyBatis-Plus的单表CRUD几乎不需要写SQL——它内置了通用Mapper，你只需要定义实体类，基础的增删改查方法直接用就行。复杂查询（比如多表关联统计）再手写SQL，这样开发效率提升非常明显。答辩时老师如果问“MyBatis和MyBatis-Plus的区别”，你要能说出这一点：MyBatis-Plus是MyBatis的增强工具，只做增强不做改变，核心卖点是通用Mapper和条件构造器。

数据库用MySQL 8.0没什么好说的，存储引擎务必选InnoDB，支持事务和外键约束。这里有个细节要注意：数据库连接串记得加上serverTimezone=Asia/Shanghai参数，否则日期时间字段会出现时区偏差问题，我见过太多人在这个细节上翻车。

2.2 核心模块划分

整个系统按功能边界拆成六个核心模块，每个模块各司其职：

系统管理模块：管理员账号管理、角色权限控制、操作日志。这是所有后台系统的底座，没有它，其他模块就是裸奔。

车位管理模块：车位信息的增删改查、车位状态管理（空闲/占用/锁定）、车位的区域划分（比如A区、B区）。这部分是停车场的基础数据维护。

车辆管理模块：车辆入场登记（车牌号、入场时间、分配车位）、车辆出场结算（计算费用、生成订单、释放车位）、长期车辆管理（月卡/年卡用户）。

收费规则模块：这是整个项目的核心亮点。你可以实现按时长计费（首小时X元、后续每小时Y元、封顶Z元）、按次计费、夜间免费时段、节假日折扣等多种策略。把这个模块做成可配置的，而不是写死在代码里，就是加分项。

统计报表模块：今日营收、车流量走势、车位利用率、收入来源分析（临时车VS月卡车）。你可以用ECharts在管理端画几个图表，演示效果直接拉满。

大屏展示模块：如果说统计报表是给管理员看的，大屏就是给评委和参观者看的。一块展示实时车位占用情况、今日车流、营收数据的可视化看板，演示效果非常加分。

2.3 数据库设计：七张核心表的结构与关联

数据库设计是毕业设计的重头戏，也是答辩时老师必看的部分。表结构设计得好不好，直接决定了后面代码好不好写。我按实际开发经验，整理出下面这套经过验证的表结构方案：

用户表（sys_user）

• 字段：id、username、password（BCrypt加密存储）、real_name、role（admin/operator/super_admin）、status、create_time
• 说明：用户表就是管理员表，别跟车主表混在一起。车主信息直接用车辆表关联即可，不需要单独建用户表，不然逻辑会绕。

车辆信息表（car_info）

• 字段：id、plate_number（车牌号，建唯一索引）、owner_name、owner_phone、car_type（临时车/月卡车/免费车）、monthly_card_expire（月卡到期时间）、create_time
• 说明：这张表是整个系统的关键线索。车牌号唯一索引是必须的，因为入场出场都是靠车牌号来识别车辆身份。

车位信息表（parking_space）

• 字段：id、space_no（车位编号）、space_area（所属区域）、space_type（普通车位/新能源车位/无障碍车位）、status（空闲/占用/锁定）、current_car_id（当前停放车辆ID，外键关联car_info）、update_time
• 说明：这是判断停车场是否“满员”的基础。status字段要建索引，因为查询空车位是整个系统最高频的操作。

停车记录表（parking_record）

• 字段：id、car_id（外键关联car_info）、space_id（外键关联parking_space）、entry_time、exit_time、duration_minutes、total_amount、status（停泊中/已结算/异常订单）、operator_id（操作员ID）
• 说明：这是系统最核心的业务流水表。每辆车入场生成一条记录，出场时更新这条记录而不是新建一条，这样所有历史流水都留存在同一张表里，统计数据非常方便。

收费规则表（charging_rule）

• 字段：id、rule_name、rule_type（时长计费/按次计费）、free_duration_minutes（免费时长）、first_hour_fee（首小时费用）、additional_hour_fee（追加每小时费用）、daily_cap_amount（每日封顶金额）、night_free_start（夜间免费开始时间）、night_free_end（夜间免费结束时间）、effective_status、create_time
• 说明：这张表是“运营平台”的点睛之笔。把计费逻辑做成可配置的，而不是代码写死，整个系统的灵活性和商业价值立马不一样。

订单表（parking_order）

• 字段：id、order_no（订单编号，生成规则可以做成日期+随机数）、record_id（关联停车记录）、pay_amount、pay_type（现金/微信/支付宝/月卡抵扣）、pay_status（待支付/已支付/已退款）、pay_time、operator_id
• 说明：订单表可以单独建，也可以直接合并到停车记录表里。我建议单独建，因为订单意味着“支付行为”，字段和责任更清晰，而且后面如果要接支付接口，订单表是必须的。

操作日志表（operation_log）

• 字段：id、operator_id、operation_type、operation_content、operation_time、ip_address
• 说明：用于记录管理员的关键操作，比如修改了收费规则、强制出场某个车辆。这既是安全审计需求，也是答辩时的加分细节——“我们这个系统具备完整的操作留痕能力”。

这套表结构是一对多关系为主的经典范式：一张car_info对应多条parking_record，一条parking_record对应一条parking_order，parking_space和parking_record之间是一对一的当前占用关系。关系的清晰度，在答辩时用ER图一画，老师立刻就能看出你的设计功底。

3. 核心业务流程与关键实现细节

3.1 车辆入场流程：从车牌识别到车位分配

入场是整个系统第一个核心流程。现实中的停车场通过摄像头自动识别车牌，毕业设计阶段你可以模拟这个过程——管理员在后台输入车辆的车牌号，系统自动完成后续操作。

入场流程的核心逻辑：

public ParkingRecord vehicleEntry(String plateNumber, Long spaceId) { // 1. 校验车辆信息，如果是未登记的新车，先自动建档 CarInfo carInfo = carInfoMapper.selectByPlateNumber(plateNumber); if (carInfo == null) { carInfo = new CarInfo(); carInfo.setPlateNumber(plateNumber); carInfo.setCarType(CarType.TEMPORARY); carInfoMapper.insert(carInfo); } // 2. 校验车牌号是否已经在场内（防止重复入场） // 这一点极易遗漏！有些车辆出场时没结算成功，导致系统里一直有一条“停泊中”的记录 // 3. 分配车位：优先分配同区域的空闲车位，如果没有空闲车位则提示“车位已满” // 可以设计为自动分配：select * from parking_space where status = 'FREE' limit 1 // 4. 锁定车位，创建停车记录 // 需要开启事务：扣减车位 + 插入停车记录，两步必须同时成功 // 5. 记录操作日志 }

这段逻辑在面试或者答辩时，最值得展开讲的就是事务问题。入场操作涉及两步写操作：更新车位状态为“占用”、插入一条停泊中的停车记录。这两步必须放在一个事务里，否则会出现车位显示占用但系统无记录、或者有记录但车位还是空闲的数据不一致问题。

3.2 车辆出场与计费：核心算法怎么设计

出场流程比入场复杂，因为涉及计费。计费算法是整个项目的灵魂，你需要认真设计。

基础计费逻辑伪代码如下：

public BigDecimal calculateFee(ParkingRecord record, ChargingRule rule) { long durationMinutes = Duration.between(record.getEntryTime(), LocalDateTime.now()).toMinutes(); // 1. 免费时长判断 if (durationMinutes <= rule.getFreeDurationMinutes()) { return BigDecimal.ZERO; } // 2. 按次计费 if (rule.getRuleType() == RuleType.PER_ENTRY) { return rule.getFirstHourFee(); } // 3. 按时长计费：首小时 + 追加小时 BigDecimal totalFee = rule.getFirstHourFee(); long additionalMinutes = durationMinutes - rule.getFreeDurationMinutes() - 60; if (additionalMinutes > 0) { long additionalHours = (long) Math.ceil(additionalMinutes / 60.0); totalFee = totalFee.add(rule.getAdditionalHourFee().multiply(BigDecimal.valueOf(additionalHours))); } // 4. 封顶金额判断 if (totalFee.compareTo(rule.getDailyCapAmount()) > 0) { totalFee = rule.getDailyCapAmount(); } return totalFee; }

这里面有几个细节需要特别提醒：

金额计算务必使用BigDecimal，不要用double或float。这个不是小题大做——二进制浮点数在计算金额时会出现精度丢失，比如0.1+0.2=0.30000000000000004，这在涉及金钱的场景是绝对不可接受的。

时长计算要向上取整。停车1小时01秒，按2小时收费，这是行业惯例。Math.ceil可以帮你实现。

免费时段判断不要写死在代码里。把夜间免费时段的起止时间放在收费规则表里，管理员可以在界面上配置，这才是“运营平台”该有的姿态。

出场操作还要处理订单生成和收款状态。如果你做线下收费场景（现金扫码），出场时更新停车记录的状态、释放车位、生成订单，这三步同样要在一个事务里完成。

3.3 月卡与长期车辆：别做成鸡肋功能

很多同学做月卡功能，就是在车辆信息表里加一个字段“is_monthly_card”，然后出入场都不收费了。这样做太简单，也没有实际管理意义。

稍微像样一点的实现应该包含：

• 月卡续费：在管理端为长期车辆办理续费，更新月卡到期时间。
• 到期提醒：系统在月卡到期前7天、3天、1天生成提醒，管理员在首页可以看到“即将到期车辆”列表。
• 过期处理：月卡过期后，车辆再入场时按临时车标准计费，出场时提示“月卡已过期，按临时车收费”。
• 月卡充值记录：记录每次续费的金额、时长、操作员。这样财务上才能查账。

把月卡做成独立的功能模块，而不是一个标记字段，这会让你的系统在功能完整度上拉开同学一个身位。

3.4 登录鉴权：用Sa-Token还是JWT

登录鉴权是每个后台系统的刚需。技术方案上有两个主流选择：

JWT（JSON Web Token）：无状态、跨域友好、天然适合前后端分离。但JWT有个明显的坑——Token签发后无法主动失效，如果管理员改了密码，旧Token依然有效，除非你自己实现Token黑名单机制。

Sa-Token：国产轻量级鉴权框架，核心思路是“登录后把Token存到服务端（Redis或内存），注销时直接删除”，天然支持主动失效和会话管理。API设计很简洁，登录只需要一行StpUtil.login(userId)。

如果你在简历上写“精通Spring Security”，那可以挑战一下Spring Security+JWT，但说实话这套组合的学习曲线比较陡峭，对毕业设计来说属于性价比很低的方案。我给的建议是：选Sa-Token。理由很简单——够用、简单、代码干净，而且答辩时你能清清楚楚讲出它的设计思路，这比背一堆Spring Security的过滤器链概念要实在得多。

3.5 Redis在项目里的定位：缓存与分布式锁

Redis在这个项目里可以做两件事：

缓存热点数据：比如车位剩余数量、收费规则列表，这些数据被高频读取但低频修改，非常适合缓存。但要注意缓存一致性，更新收费规则后要主动清除或更新缓存，否则会出现“改了半天规则，计费还是老样子”的诡异bug。

分布式锁解决并发入场：想象一个场景——停车场只剩最后一个车位，两辆车几乎同时入场，如果不用锁，两个请求都可能查到“有空闲车位”，然后都执行入场逻辑，导致车位超卖。这本质上和电商秒杀超卖是同一个问题。

最简单的方案是用Redis的setnx命令实现一个轻量锁：

Boolean locked = redisTemplate.opsForValue().setIfAbsent("lock:parking:entry", "locked", 10, TimeUnit.SECONDS); if (!locked) { throw new BusinessException("系统繁忙，请稍后重试"); } try { // 执行入场逻辑 } finally { redisTemplate.delete("lock:parking:entry"); }

答辩时能把这个并发场景讲清楚，属于非常硬核的加分项。很多同学做管理系统根本没考虑过并发问题，你能主动说出来，说明你思考过真实环境下的运行状态。

4. 从零到部署：完整实操过程记录

4.1 环境准备与项目初始化

工欲善其事，必先利其器。动手写代码之前，先把环境装好：

• JDK 1.8 或 11（建议1.8，兼容性最好，大部分公司老项目还是以1.8为主）
• Maven 3.6+（用来管理依赖和打包）
• MySQL 8.0+（本地装一个，别用云端数据库做开发，调试麻烦）
• Redis 5.0+（Windows用户可以用微软移植版或者Docker装）
• IDEA 2023版本以上（社区版就够用，没必要破解旗舰版）

项目初始化用IDEA的Spring Initializr最方便：选好SpringBoot版本、勾选Lombok、Spring Web、MyBatis（之后在pom.xml里手动加MyBatis-Plus依赖）、MySQL Driver、Validation。注意SpringBoot的版本选择，我推荐2.7.x而不是3.x——3.x是基于Jakarta EE的，很多老教程的代码在3.x上跑不通，而且部分第三方starter还没适配完，没必要给自己挖坑。

4.2 后端代码结构：包名怎么分、代码怎么组织

包结构是代码规范的第一张脸，我见过太多同学的代码全部堆在controller里，一个方法写几百行，这种代码别说答辩，自己回头调试都头疼。合理包结构参考如下：

com.smartparking ├── controller // 接口层，只做参数接收和响应封装 │ ├── AdminController │ ├── CarController │ ├── ParkingController │ └── StatisticsController ├── service // 业务层，核心逻辑全部写在这里 │ ├── impl │ ├── ParkingService.java │ ├── ChargingService.java │ └── StatisticsService.java ├── mapper // 数据访问层，MyBatis-Plus的Mapper接口 ├── entity // 实体类，对应数据库表 ├── dto // 数据传输对象：接收前端参数、返回前端响应 ├── common // 通用类：统一返回结果Result、异常处理、常量定义 ├── config // 配置类：跨域配置、拦截器、Redis配置 └── utils // 工具类：JWT工具、日期工具、车牌校验工具

分层的核心法则：Controller只干活不决策，Service只做业务不碰HTTP，Mapper只碰数据库不写逻辑。这样职责清晰、代码可读性强，答辩时老师一眼就能看出你有工程化意识。

4.3 从数据库到接口：15个核心接口的完整实现

这个项目后端要做多少个接口才算是“完整系统”？我按模块给你梳理一遍，总共大概15-18个接口。每个接口都对应一个具体的业务场景，做完这些，系统的功能闭环就完整了：

系统管理模块（3个接口）

• 管理员登录（POST /api/auth/login）：接收用户名密码，校验后返回token
• 管理员登出（POST /api/auth/logout）：清除服务端会话
• 获取当前登录用户信息（GET /api/auth/info）

车位管理模块（3个接口）

• 车位列表（分页+状态筛选）（GET /api/spaces）
• 新增/修改车位（POST/PUT /api/spaces）
• 删除车位（DELETE /api/spaces/{id}）

车辆管理模块（4个接口）

• 车辆入场（POST /api/vehicle/entry）：核心接口，入参是车牌号和车位ID
• 车辆出场（POST /api/vehicle/exit）：核心接口，入参是车牌号或停车记录ID
• 车辆列表查询（GET /api/vehicles）
• 月卡办理/续费（POST /api/vehicles/renew）

收费规则模块（2个接口）

• 查询当前生效的收费规则（GET /api/charging/current）
• 修改收费规则（PUT /api/charging/rule）

统计报表模块（3个接口）

• 今日概览数据（GET /api/statistics/today）：今日营收、车流量、当前占用
• 营收趋势（GET /api/statistics/revenue-trend）：近7天/30天营收曲线
• 车位利用率（GET /api/statistics/utilization）：各区域车位利用率百分比

订单模块（2个接口）

• 订单分页查询（GET /api/orders）：按订单号/车牌号/时间范围筛选
• 订单详情（GET /api/orders/{id}）

统一的返回结果类是必须的。我一般这样定义：

@Data public class Result<T> { private Integer code; // 200表示成功，400业务错误，401未登录，500系统异常 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } }

前端（Vue端）封装的axios拦截器，统一处理code——code不是200就弹出错误提示，401就跳转登录页。这套设计模式是行业标准，直接抄。

4.4 前端实现要点：有没有必要写大屏可视化

前端部分，如果你选择Vue，管理后台的页面大概需要：登录页、首页仪表盘（今日营收、车流量、车位占用概览）、车位管理页、车辆管理页、停车记录页、收费规则配置页、订单管理页、大屏展示页。

这里认真聊聊大屏可视化。很多同学会觉得大屏很难，实际上现在用ECharts做可视化非常快，核心就是三个图：

• 实时车位占用环形图：用饼图展示空闲/占用/锁定的比例
• 近7日车流量柱状图：每天的进场车辆数
• 近7日营收折线图：每天营收金额变化

这三个图表就足够撑起大屏的视觉冲击力了。技术实现上，前端定时（比如每10秒）轮询后端统计接口，刷新图表数据，就有“实时”的效果。如果你想做得更高级一点，可以用WebSocket做实时推送，但这属于锦上添花，不是必须。

我个人建议：大屏要写，但别在它上面花超过两天时间。它的核心价值是演示效果好，对项目技术深度的贡献有限。时间应该花在关键业务逻辑上，比如计费算法的严谨性、并发入库的处理——这些才是答辩时真正能扛住深挖的点。

4.5 答辩演示脚本：5分钟流程怎么走

项目做完，答辩演示也是门技术活。很多同学开发得挺认真，演示的时候手忙脚乱，项目亮点一个没展示出来，很亏。我建议准备一个5分钟的演示脚本，按照下面的顺序走：

第一分钟：登录系统，展示首页仪表盘——快速介绍项目的整体功能，让老师对系统规模有个感性认识。

第二分钟：创建一个收费规则（比如“首小时5元，后续每小时3元，单日封顶30元”）——演示收费规则的可配置性，这是“运营平台”的关键特征。

第三分钟：车辆入场操作——录入一个车牌号GB12345，系统自动分配车位。然后去车位管理页展示该车位状态已变为“占用”。

第四分钟：车辆出场操作——录入同一个车牌号，系统自动计算停车费用。刻意停顿一下，把计费明细展示给老师看：“入场11分钟，未超过免费时长，收费0元”或者“入场2小时15分，按3小时计费，总费用11元”。

第五分钟：打开统计报表或大屏——展示今日营收曲线、车位利用率等图表。最后补一句：“这些图表的数据是从停车记录表实时汇总计算得出的”。

整个演示过程的核心原则是：让老师看到完整的业务闭环——配置规则、入场、计费、出场、统计，一条线走完，整个系统的价值一目了然。

5. 常见问题与避坑经验

5.1 代码层面的“坑”与解决方案

问题一：日期时间差了8小时

原因：服务器时区是格林尼治标准时间，而中国是东八区。表现是数据库里存的时间和本地时间差了8小时。排查方法：查看数据库连接串是否加了serverTimezone=Asia/Shanghai，以及JVM启动参数是否设了-Duser.timezone=GMT+8。

问题二：BigDecimal传参精度丢失

前端传金额给后端时，如果用JSON标准格式传数字，小数位数可能会被截断。解决方案：前端把所有金额字段转成字符串传输，后端用@JsonFormat或自定义反序列化器处理字符串到BigDecimal的转换。

问题三：MyBatis-Plus分页查不出数据

大概率是没配置分页插件。MyBatis-Plus的分页功能需要显式添加PaginationInnerInterceptor，在配置类里注册一下：

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }

问题四：Lombok在IDEA中提示找不到getter/setter

这不是代码问题，是IDEA没装Lombok插件或者没开启注解处理。设置里搜“annotation processing”，勾选“Enable annotation processing”，再装一下Lombok插件，重启即解决。

问题五：跨域请求报403或CORS错误

前后端分离部署时，跨域是最常见的问题。简单做法是在后端写一个配置类实现WebMvcConfigurer，重写addCorsMappings方法允许所有来源。但注意，如果你后续接了权限拦截器，跨域预检请求（OPTIONS请求）会被拦截器拦掉，需要在拦截器里对OPTIONS请求直接放行。

5.2 时间管理和开发节奏

如果现在是毕业设计启动初期，建议按照下面的节奏推进：

第1周：完成需求分析、数据库设计、项目初始化。这周是最重要的，地基没打好后面全是返工。

第2-3周：完成后端核心业务：登录鉴权、车位管理、入场/出场流程。这是系统的骨架。

第4周：完成计费规则、统计报表、订单管理。这时候系统已经能跑通完整闭环了。

第5周：写前端页面，对接接口。如果你前端不熟，这周是最大的瓶颈期，建议提前规划好页面数量和交互复杂度。

第6周：部署、测试、写论文、准备答辩PPT。最后留一周缓冲，处理意外问题。

5.3 答辩老师最爱问的几个问题

提前把这些问题想清楚，答辩时就不慌：

为什么选择SpringBoot？答：SpringBoot简化了Spring的配置复杂度，内置Tomcat，起步依赖自动管理jar包，非常适合快速构建独立运行的微服务应用。（顺着这个回答可以展开聊自动配置原理）

你的系统跟别的停车管理系统相比有什么亮点？答：第一，收费规则可配置化，运营人员无需改代码就能调整计费策略；第二，使用Redis分布式锁解决并发入场场景下的车位超卖问题；第三，系统内置统计报表模块，便于管理者做运营分析。（建议直接背下来）

数据库表为什么这样设计？答：采用三范式设计，车辆表、停车记录表、订单表分离，各自记录不同维度的业务数据。车位表和停车记录表之间是一对一关系，因为一个车位同一时间只能停一辆车。同时通过外键关联保持数据一致性。（画ER图的时候把这些关系指给老师看）

如果停车记录有异常数据（比如入场了但没出场记录），如何发现和处理？答：系统会定期扫描停车记录表，找出“停泊中”状态但已超过最大停车时长的记录，标识为异常订单，管理员可以手工处理。还可以写一个定时任务，每日凌晨扫描未关闭的记录并生成提醒。

5.4 论文写作的侧重点

最后聊两句论文。毕业论文不要全篇写代码，而是要突出“设计思路”和“解决问题的方法”。比较好的结构是：

• 绪论：研究背景、国内外现状、研究内容
• 相关技术介绍：SpringBoot、MyBatis-Plus、Redis、Vue
• 系统需求分析：功能需求、非功能需求（性能、安全性、易用性）
• 系统设计：架构设计、功能模块设计、数据库设计
• 系统实现：各模块的关键代码（注意不是贴全部代码，是贴核心逻辑段）
• 系统测试：功能测试用例表、测试结论

答辩论文里一定要放几张截图：数据库ER图、系统架构图、核心功能界面图。图比字重要得多，这是论文答辩的通用法则。

写论文的时候，我建议先搭框架再填充内容，不要想到哪写到哪。框架搭好后每天推进一个章节，一周到十天就能出完整初稿。

这个停车场管理系统的题目，说难不难，说简单也绝对不简单。关键在于你是否把核心业务逻辑想透了——入场出场的状态流转、计费规则的灵活设计、并发场景的数据一致性，这三个点做好了，你的项目就站在了“管理系统”和“运营平台”的分界线上。

我个人在做类似项目时最大的体会是：别急着写代码，先把入场出场的整个状态流转画清楚。状态机理清楚了，数据库表和业务代码都是水到渠成的事情；状态机含糊，代码写再多也是空中楼阁。做毕业设计如此，以后进公司做真实项目更是一个道理。

再有就是动手之前花两小时把技术栈定下来，版本、包结构、统一返回格式这些约定提前说好，后面写代码会顺畅很多。祝你项目顺利，答辩稳过。