1. 项目整体设计与技术选型
班车预约管理系统这个题目，几乎每年计算机毕业设计里都能看到，但真正能把它做得“能答辩、能运行、能演示、经得起追问”的却不多。很多人拿到“springboot班车预约管理系统”这个题目就慌了，第一反应是去CSDN或者GitHub找个现成的工程，改个皮就交差。这种做法表面省事，但一到答辩环节，老师问一句“这个表为什么这么设计”“Redis在这里解决什么问题”，基本就卡壳了。实际上，班车预约这个场景在业务上非常典型，背后涉及的Spring Boot技能点十分密集：路由表设计、时间窗口冲突校验、座位状态并发控制、用户权限体系，再到接口文档输出。把这些点逐个讲清楚，不仅毕业设计稳了，以后入职做企业级业务系统时照样用得上。
先说清楚这套系统到底是干什么的：它服务于一个固定运营场景，比如公司员工通勤班车、校园接驳巴士、产业园区的定时班线。用户注册登录后，可以看到班车线路、发车时间、余座数量，提交预约申请；管理员可以维护车辆、线路、站点，审核用户提交的预约请求，也可以处理取消和改签。整个系统本质上是一个小规模的预定引擎，核心挑战不是页面炫不炫，而是几个关键点：“一个座位会不会被两个人同时约走”“班车站点到站时间怎么算出来的”“用户约了车不去该不该有惩罚机制”。项目编号18530指的是一套以Spring Boot为后端的完整工程方案，源码组织上分为前端展示、后端服务、数据库脚本三部分。
1.1 为什么选Spring Boot而不是SSH或者纯Servlet
很多刚做毕设的同学都会纠结技术栈的选择。网上到处是“SSH框架已过时”的说法，但真正的原因不是过时，而是工程效率。SSH（Spring + Struts + Hibernate）时代，光配置XML文件就能折腾出几百行，而且Struts 2的动作类与Servlet API耦合很深，调试时顺藤摸瓜找配置文件非常痛苦。Spring Boot把这个周期压缩到最低限度：内嵌Tomcat、自动装配、起步依赖，写一个Controller从新建到运行基本不需要手动部署容器。
这个项目选用Spring Boot 2.x系列是稳妥的选择。我见过不少同学图新，直接起一个Java 21配合Spring Boot 3.x，结果数据库驱动、Redis客户端、MyBatis插件的兼容性问题堆了一堆，最后为了版本折腾掉一周。毕设的核心目标是先把业务跑通、把功能演示做好，稳定压倒一切。Spring Boot 2.7.x配JDK 8或11，再配MyBatis-Plus，这套组合在社区里大量存在，遇到问题搜索一下就有答案，真正意义上属于“踩坑成本最低”的方案。
1.2 前后端分离还是服务端渲染
这个决策直接影响整个项目的开发节奏。班车预约系统如果采用服务端渲染模板（比如Thymeleaf），控制器层要同时兼顾页面跳转和数据返回，每一个功能页面都得写对应的视图模板，前端交互效果很受限。如果采用前后端分离，后端只输出JSON，前端用Vue或React搭建，工作量又摊到了前端那边。考虑到毕设时间通常只有几个月，期间还要写论文、画图、准备答辩PPT，个人强烈建议：
- 如果前后端都是自己写，选Thymeleaf + Bootstrap，最少代码量完成全部功能，省去接口联调成本。
- 如果前端已经有Vue基础，选Spring Boot + Vue，前后端分离本身就是亮点，答辩时能展示RESTful API设计和跨域配置。
- 如果打算直接改造开源前端，要确保理解每一个请求的流转过程，而不是只会Ctrl+C / Ctrl+V。
这套系统源码18530采用的是前后端分离的RESTful接口组织方式，接口返回统一结构体，前端按需调用，这样设计在将来扩展到微信小程序或钉钉微应用时也能复用同一套接口。
2. 核心需求拆解与数据模型设计
任何项目开工之前，先把需求拆成用户故事。班车预约系统的主要角色有三个：普通用户、管理员、系统（自动调度逻辑）。普通用户关心的是“有什么车”“几点发”“还有没有位”“怎么取消”；管理员关心的是“今天哪些班车满载”“某个用户约了车没坐”“哪条线路要调整班次”；系统需要处理的是“预约冲突”“取消窗口超时解锁座位”“每日定时重置余座”。
2.1 实体关系设计与表结构规划
数据库设计决定了系统能不能回应上面这些需求。一张合理的表结构图，比一百页文档都实在。核心表至少包括：
用户表（sys_user）：存储用户基础信息，登录账号、密码（BCrypt加密）、姓名、部门、手机号、角色标识。毕业设计一般不需要单独建权限表，用一个role字段区分USER和ADMIN就够。
班车线路表（route）：线路名称、起点、终点、发车时间、到达时间、经停站点的名称列表（用JSON字符串存）。
班次表（schedule）：一条线路每天可能跑多趟，每个班次绑定一条线路，记录日期、发车时间、总座位数、余座数、车辆编号、司机信息。这里要注意把“线路基础信息”和“某一天的具体班次”拆开，否则数据冗余得很难看。
预约记录表（booking）：预约人ID、班次ID、预约时间、乘车状态（待乘车/已乘车/已取消/爽约）、座位号、创建时间和更新时间。
站点表（station）：站点名称、经度、纬度、所属线路。如果想做“附近的班车站点”这个功能，经纬度就有用了，不过毕设阶段不强制要求。
表结构如果按这套来设计，后面写MyBatis的Mapper会非常顺畅。一些同学喜欢把线路直接绑死到班次表里，导致同一条线路一天发5趟车就得复制5份线路名、起点终点，查询列表时还要用GROUP BY去重，这是纯给自己挖坑。
2.2 数据库外键的一存一不存原则
初学者最爱犯的问题就是“见到关联就强加外键”。班次表里存了route_id，预约记录表里存了schedule_id和user_id，这已经很清晰了。但如果你把“用户姓名”也冗余存到预约记录表里，一旦用户改了名，历史预约数据就变成错的了。正确做法是只存ID，需要展示时通过SQL JOIN或者MyBatis-Plus的关联查询把用户姓名带出来。同理，班次表的余座字段，不要在数据库层面再关联一张“座位表”，除非你真的要精确到每个座位的排布图。
这里需要一个额外的缓存字段逻辑：余座数量直接冗余存储在schedule表中，通过乐观锁版本号控制并发扣减。有人会问为什么不单独建一张座位表逐座管理，理论上是可行的，但毕设场景下用户量没那么大，统计每个具体座位号反而增加复杂度，冗余余座字段+乐观锁已经够用。
2.3 状态机是预约系统的灵魂
预约状态不能设计成随意字符串乱填。个人建议，在Java代码里直接用枚举类定义状态流转，数据库字段存字符串或数字。状态之间的合法转换关系如下：
待乘车（BOOKED） -> 已乘车（COMPLETED） 待乘车（BOOKED） -> 已取消（CANCELLED） 待乘车（BOOKED） -> 爽约（NOSHOW） // 发车后未乘车且未取消这里不能允许从“已取消”再变成“已乘车”，逻辑上已经不可能。MyBatis的Update语句里带上where status = 'BOOKED'这种条件更新，正好可以挡住这种非法状态流转。这也为后面讲并发控制做了铺垫。
3. 核心功能实现与关键代码解析
这一部分是整篇博文的重点，也是最容易被大家忽略的。班车预约系统表面是个CRUD项目，实际上隐藏着不少业务逻辑细节，尤其是“预约/取消/查询余座”这三个高频操作，背后涉及并发和事务边界的问题，一旦处理不好，答辩时被追问就露馅了。
3.1 登录鉴权和用户角色权限控制
用户登录是整个系统的基础。密码存储绝不能明文，Spring Boot里引入spring-security-crypto依赖，使用BCryptPasswordEncoder对密码做哈希。登录成功后，用JWT生成一个Token返回前端，前端在后续请求中把Token放到Header里，后端用拦截器解析Token并获取当前用户ID。
角色权限控制我建议用简单的拦截器做：配置一个WebMvcConfigurer，给需要管理员权限的路径（比如/route/、/schedule/）单独加拦截判断。不需要引入Spring Security全家桶，因为Spring Security的过滤器链配置对毕设来说太繁琐，而且稍微配错就会出现“登录后进不去页面”这种崩溃问题。你只需要一个注解@RequireAdmin或者写死路径匹配都能达到同样的效果，答辩时也能自圆其说：在复杂权限场景下可以考虑Spring Security，但当前系统角色较少，拦截器方案实现简单、性能开销更低。
需要展示的核心代码如下：
public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { throw new BusinessException("未登录或登录已过期"); } Long userId = JwtUtil.parseToken(token); if (userId == null) { throw new BusinessException("Token无效"); } request.setAttribute("userId", userId); return true; } }3.2 座位预约不超卖的实现方案
“座位余量”是一个典型的并发控制问题。假设现在班次剩余座位只剩下1个，两个用户同时点击预约，如果没有处理并发，数据库的余座字段可能被减成-1，这就是超卖。解决超卖有几种途径：悲观锁、乐观锁、Redis预扣减。
毕业设计这个级别，我建议直接用数据库乐观锁。schedule表增加一个version字段，更新时条件带上version = 当前查到的值，如果更新影响行数为0，说明版本变了，预约失败，提示“余座已被抢光”。
UPDATE schedule SET remain_seats = remain_seats - 1, version = version + 1 WHERE id = #{scheduleId} AND remain_seats > 0 AND version = #{version}这条SQL在MyBatis里执行时，不需要手工开启事务，因为单条UPDATE本身就具备原子性。配合@Transactional标注的service方法，整个预约流程变成：查询班次信息 -> 插入预约记录 -> 更新余座。如果第三步返回0行，直接抛出异常回滚第二步。
需要注意的是，不要用“先查询余座再判断然后在Java层面扣减”这种写代码方式。这一步非原子操作注定会出现超卖，无论多少个面试官或答辩老师追问，你都可以坚定回答：最终一致性靠数据库约束来兜底。
如果项目里已经引入了Redis，可以升级方案：先用Redis的DECR命令预扣，扣减后的值小于0说明没座位了，同时把请求量挡在数据库前面。但Redis和数据库之间会存在缓存不一致的情况，需要额外的补偿机制，毕业设计不推荐，说清楚就行。
3.3 取消预约与座位释放的时机处理
取消预约是实现比较微妙的功能。业务规则是：用户可以在发车前X小时取消预约，取消后释放座位。这个时间窗口怎么定？可以用发车时间减去当前时间来判断。如果允许发车前30分钟取消，那么SQL条件就写成：
LocalDateTime now = LocalDateTime.now(); LocalDateTime cancelDeadline = schedule.getDepartureTime().minusMinutes(30); if (now.isAfter(cancelDeadline)) { throw new BusinessException("距离发车不足30分钟，无法取消预约"); }但是还有一个问题：发车后用户没来也没取消，座位一直占着怎么办？这里需要定时任务出马。Spring Boot中启用@EnableScheduling注解，写一个ScheduledTask，每小时扫描所有“BOOKED”状态但发车时间已经过去1小时的预约记录，统一改成“NOSHOW”（爽约）状态，同时把对应班次余座回补。等等，这里回补座位要谨慎：如果发车时间已经过了，班次都结束了，座位回补没有意义，所以不加回补逻辑，只改状态。但如果系统里有“下一班可预约”的逻辑，那就在改状态前判断，不要盲目处理。
3.4 班次检索与余座查询的性能优化思路
当用户进入班车列表页，系统要显示大量班次信息和余座状态。最简单直接的查法就是联表查询+时间过滤，但数据量大了之后，建议给schedule表加索引，索引字段为(route_id, depart_date, depart_time)，这样的复合索引最贴合实际业务场景：用户指定某条线路、某个日期，快速筛选出当天所有班次。
另外一个体验优化：余座状态不要每次都去数据库count预约记录，直接从schedule表的remain_seats字段读，因为预约时已经同步更新了这个值。查询语句变成：
LambdaQueryWrapper<Schedule> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Schedule::getRouteId, routeId) .eq(Schedule::getDepartDate, date) .orderByAsc(Schedule::getDepartTime);当处理结果集时，用MapStruct或BeanUtil将实体转换成VO给前端，不要把entity里的password字段暴露出去。这里额外提醒一句：用了MyBatis-Plus，别把select *全查出来再在Java里做筛选，数据库能过滤的不要让内存去承担。
4. 实战过程中的坑与问题排查
这一章是我最想讲的内容，因为从“能运行”到“能演示”之间有大量莫名其妙的坑。很多代码逻辑明明写对了，但系统就是起不来，或者数据就是不对。下面把高频问题整理一下，按出现频率排序。
4.1 Spring Boot版本导致的JSON序列化异常
Java时间类型LocalDateTime序列化后默认是一串数组，比如"departureTime": [2024, 5, 20, 8, 30, 0]，前端拿到这玩意根本没法用。解决办法是在application.yml里统一配置日期格式：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8如果是Spring Boot 3.x，上面的配置依然有效，但要注意如果用了jackson-datatype-jsr310，确保依赖完整。版本不匹配时最常见的报错是InvalidDefinitionException: Java 8 date/time type LocalDateTime not supported，看上去像是代码问题，其实是依赖缺失。前几年还有个典型的坑是Spring Boot 2.3之后的spring-boot-starter-web不再默认带入validation的依赖，导致@Valid注解不生效，Bean Validation完全没反应，需要手动添加spring-boot-starter-validation。这类问题折磨人的地方在于不仔细看日志根本定位不到。
4.2 MyBatis-Plus字段映射与日志打印配置
MyBatis-Plus的驼峰和下划线自动映射默认是开启的。数据库字段depart_time可以自动映射到实体的departTime属性。但有的同学数据库字段叫departtime，Java属性叫departTime，那映射关系就自动失效了。如果命名不规范，就得在实体类里手动加@TableField("departtime")。
另一个让人崩溃的情况是SQL报错但看不到完整语句。MyBatis打印SQL的方法是：
mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl日志刷出来之后，可以直观看到执行的SQL和参数，排查问题快十倍。这点务必在开发阶段就配好，不然上线调试两眼一抹黑。如果你想自己写一个分页查询，记得引入分页插件：
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }不配置这个，分页功能不会生效，调用Page方法时查询的还是全量数据，这个坑困住了非常多的人。
4.3 跨域配置与前端联调的典型报错
前后端分离模式下，前端跑在localhost:5173，后端跑在localhost:8080，前端发请求浏览器直接报CORS错误。解决办法是在后端写一个跨域配置类：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }注意：allowCredentials(true)配合allowedOriginPatterns("*")在Spring Boot 2.4+版本中是允许的，以前用allowedOrigins("*")会出现“Cannot allow credentials for origin”之类的异常。如果你还在用老写法，改一下就好。
4.4 时间处理中容易忽略的时区问题
服务器时区默认可能是UTC，本地是东八区。查询“今日班次”时如果是后端生成日期条件，非常容易查询出“明天”甚至“昨天”的数据。强烈建议数据库连接串上增加参数：
jdbc:mysql://localhost:3306/shuttle?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai同时前端传入的时间格式必须统一为字符串，后端用DateTimeFormatter严格解析，不要依赖默认的LocalDateTime.parse行为，因为不同JDK版本对这个方法的格式容忍度不一样。
4.5 定时任务不执行的问题
用@Scheduled做定时任务时，如果发现任务没跑，先看启动类上有没有加@EnableScheduling。这个细节已经被无数人忽视。加了注解后默认是单线程执行所有定时任务，如果某个任务卡死，其他任务也会排队卡住。建议配置一个线程池：
@Configuration public class SchedulingConfig implements SchedulingConfigurer { @Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { taskRegistrar.setScheduler(Executors.newScheduledThreadPool(5)); } }这样每个任务都有独立的执行线程，互不阻塞。定时任务里如果要操作数据库，记得方法上加@Transactional，不然会出现“任务逻辑执行了但数据没提交”的问题。
5. 答辩前的系统演示与论文素材准备
代码跑通只是第一步，毕设最终要落实到论文和答辩。很多同学功能做得飞起，到写论文时对着屏幕发呆，不知道怎么描述系统。这里我分享自己的一个经验：写论文之前可以先把系统的接口清单梳理一遍，每个接口就是一个功能点，每个功能点配合一段截图，论文的功能模块章节基本就成型了。
5.1 演示时的数据准备与话术设计
答辩演示最怕的就是现场打开系统，发现班次列表是空的，或者测试数据全是“test1”“test2”。提前往数据库里灌一批像样的演示数据：5条线路、每条线路3个班次、若干条预约记录，状态尽量覆盖待乘车、已乘车、已取消、爽约这四种情况。用户账号统一设置成简单易记的，比如admin/admin123，避免现场登录时被密码绊住。
演示顺序要有逻辑，不要乱点。建议按下面的顺序走：
- 用户注册登录，展示JWT鉴权流程（顺便解释为什么选JWT，优势在哪）。
- 按条件查询班车，展示余座情况。
- 预约一个座位，立刻看到余座减一，数据实时变化。
- 取消预约，余座恢复。
- 管理员登录，查看所有预约记录，按线路和日期筛选。
- 管理员新增班次/修改班次，用户端刷新后立刻能看到新数据。
每一步都对应一个明确的功能点，老师看下来思路会很清晰。
5.2 论文结构建议与数据库设计说明的写法
论文结构一般包括：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。其中系统设计章节必须包含E-R图、数据库表结构说明和关键接口设计。E-R图建议自己用工具画，不要贴一张网上找的模糊截图。论文的“相关技术介绍”部分，不要长篇大论复制百度百科，写清楚Spring Boot的核心特性以及你为什么选择它即可。数据库表结构部分直接用表格列出字段名、类型、约束、说明，这比写一大段废话强得多。
5.3 老师最爱追问的十个问题提前准备
答辩时技术类问题远比你想象得刁钻，提前准备以下十个问题，基本能覆盖80%：
- 为什么选用Spring Boot，它相比传统Spring MVC有哪些优势？
- JWT是什么，Token存放在哪里，服务端如何校验Token是否有效？
- 如何防止一个座位被多个人同时预约？你是如何实现并发控制的？
- 取消预约有时间和条件限制吗？这种规则是放在前端判断还是后端校验？
- 数据库索引是怎么设计的？查询“今日班次”时索引是否生效？
- MyBatis-Plus和MyBatis有什么区别？你用的分页插件原理是什么？
- 如果数据库数据量增长到十万条，你的系统哪些地方需要优化？
- 前端如果出现跨域错误，应该怎么排查？
- 为什么要将线路和班次拆分成两张表？如果把线路信息冗余到班次表中有什么不足？
- 你的系统有哪些安全性措施？密码是如何存储的？如何防止SQL注入？
回答的时候不要背稿子，用自己的话讲清楚思路。如果某个细节答不上来，可以坦诚说“这个点考虑到时间原因还没深入，但对后续扩展有初步设想”，这种话比硬编一个答案更让人信服。
5.4 从Spring Boot扩展出去的加分方向
如果在答辩中想体现出更进一步的水平，可以主动讲一些扩展思路。例如：在现有基础上加入消息队列，比如使用RocketMQ处理“发车提醒”和“超时自动释放”异步场景；或者引入WebSocket，将班次余座更新推送到前端页面，实现实时刷新；也可以将系统改造为多租户模式，支持多个单位独立使用，隔离数据权限。这些扩展在论文中作为展望方向，属于很大的加分项。
但注意：扩展方向一定要与自己当前掌握的技术能力匹配，如果老师追问“WebSocket连接怎么鉴权”，你支支吾吾，反而会减分。宁可写一个你已做过小实验的方向，也不要写一个猜的技术。
6. 开发工具与调试技巧沉淀
这部分内容偏实操，是我个人在开发这套系统过程里沉淀下来的工具链经验。工欲善其事，必先利其器，合理的工具选择能省下大量精力。
6.1 接口调试工具和数据库可视化工具推荐
接口调试方面，现在主流的是Apifox或Postman。Apifox的优势在于自带接口文档管理，可以将接口直接同步到团队里。Postman建立Collection后也可以完整保存每套接口的请求信息。二者都会默认记录历史请求，切换环境时注意检查Header里Token是否过期。数据库工具方面DBeaver免费且支持大部分数据库，Navicat更加顺手但付费。个人经验是，如果只用MySQL且不想折腾，就用Navicat的绿色版；如果电脑内存吃紧，DBeaver更轻量。
6.2 版本控制与代码备份的建议
哪怕是一个人的毕设项目，也建议每天用Git提交一次。项目管理上分三个分支：main（稳定版）、dev（开发版）、feature（功能分支）。一天结束时提交一次，并在提交信息里写明今天完成了什么。这样即使某一天瞎改改崩了，也可以回退到昨日的版本。这比手动复制zip备份高效太多，同时也是给答辩准备的一个展示亮点：使用Git进行版本管理，本身就是一项企业级技能。
6.3 排查问题时的日志分级与检索思路
开发阶段我习惯把日志级别设置得低一些（DEBUG），方便看到SQL参数校验等细节；生产部署或演示阶段改成INFO，提高性能、减少输出噪音。通过application.yml配置：
logging: level: root: info com.example.shuttle: debug排查问题时不要漫无目的地翻日志，先看请求进来的控制层有没有接收参数，再看service层有没有抛出异常，最后看SQL的执行结果。大多数Bug都出在这三层的衔接上，特别是参数传递和类型转换阶段。这个排查思路表面很基础，但很多同学是一出问题就怀疑框架问题，最后浪费了大量时间才发现是Mapper里少写了一个条件。
7. 系统部署与运行环境配置
毕设最终提交或者展示时，通常需要一份能一键部署的说明。Windows或Linux环境下，利用Maven打包Spring Boot项目成一个可执行JAR包，一条Java命令就能启动。这里把部署和生产环节的关键点说清楚。
7.1 Maven打包与常见打包失败问题
在项目根目录执行：
mvn clean package -DskipTests打包好的JAR文件在target目录下。这一步常见的问题是：BUILD FAILURE报错，但日志信息被淹没。先用mvn -version确认Maven版本和Java版本兼容，再检查是否使用了阿里云镜像仓库的依赖导致某些依赖拉取失败。如果报错信息指向某个测试类，直接加上-DskipTests跳过测试。还有一个低级但常见的错误：主类没有按照Spring Boot规范放在src/main/java下的根包里，导致启动时找不到@SpringBootApplication注解。
7.2 Windows下直接启动JAR包的过程
Windows环境中，制作一个start.bat脚本就能实现双击启动：
@echo off java -jar shuttle-system.jar pause脚本放在JAR包同一目录，每次修改代码重新打包后替换JAR文件即可。如果端口被占用，启动日志里会有Port 8080 was already in use的提示，解决办法是换一个端口，不推荐直接杀掉占用进程，因为可能误杀其他服务。
7.3 数据库初始化脚本的整理技巧
把建库建表和测试数据语句分别写到schema.sql和data.sql，放在项目的sql文件夹下。数据库初始化时使用Navicat或命令行执行，执行一遍能自动建表并填充演示数据。这样老师拿走的项目在本地把数据库导入后就能直接跑起来，避免“代码在我电脑上可以运行，到你电脑就废了”这种尴尬状况。
8. 个人经验与注意事项总结
最后分享几点我在实际调试这个项目时总结出的通用原则，对做任何基于Spring Boot的毕设系统都有参考价值。
第一条：先跑通主流程，再补细节。很多同学第一天就纠结于前端样式是否好看、菜单颜色是否统一。实际上，对毕设来说，核心优先级永远是：用户能登录 -> 能预约班车 -> 能查看预约记录 -> 管理端能审核和维护数据。主流程跑通了，项目就具备了演示价值，后面的细节优化才有意义。一开始就抠细节的人，很容易陷入“页面调好了但数据库还连不上”的怪圈。
第二条：不要掩盖异常，要让它暴露出来。在开发阶段，任何异常都不应该被catch之后静默吞掉。一个经典的错误写法是：
try { bookingService.addBooking(bookingDTO); } catch (Exception e) { // 直接忽略 }其结果就是页面显示“操作成功”，数据库里根本没插入记录。正确做法是把异常包装成统一业务异常抛出，由全局异常处理器返回给前端一个明确的错误码和错误信息。这种设计在答辩时也能展示你自己对异常处理的理解，是一个不小的加分点。
第三条：学会阅读异常堆栈信息。面对NullPointerException，不要只盯着最后一行，堆栈信息是从下往上看，一层层找到你业务代码中真正出错的那一行。排查多了你就会发现，绝大多数离谱问题都是最常见的基础问题：参数为null、数据库连接失败、Mapper语句写错。先看最后三行，再往上翻十行，通常能定位80%的问题。
第四条：功能开发顺序与前端页面挂钩。后端的Controller和Service可以先写好，使用Apifox直接模拟前端发送请求测试；前端页面可以后置开发，因为接口已经固定了。这样两边并行不悖，整体进度推进会非常顺。
班车预约管理系统这个题目，用到的东西几乎覆盖了Spring Boot开发的最核心环节：实体建模、数据持久化、并发控制、状态流转、定时任务、RESTful接口设计、权限校验。做完这个项目，你学到的不是“怎么填一个毕设空”，而是怎么去分析一个实际业务，并企业级工程的方式把它落地。把这个思路掌握了，后续换任何管理系统题目，万变不离其宗。答辩时自信一点，让代码替你说清楚一切。
