企业官网建设流程全解析

又到一年毕业设计选题季，每年这个时候我都能在后台收到一堆私信，问的无非是"SpringBoot做什么题目好""酒店管理系统是不是太老套""CRUD一大堆会不会被答辩老师怼"。这些问题的背后其实是同一个根源：大家不太清楚毕业设计这种东西，评委到底想看到什么。作为一个带过不少毕业生、也参与过答辩评审的过来人，我可以明确地说，SpringBoot酒店预定系统这个题目，看着普通，实际上做好了，能碾压一批搭着微服务架子却空壳一个的选题。这篇文章我就把这个题目从立项到答辩的所有关键环节拆开揉碎了讲一遍，包括技术选型背后的逻辑、数据库该怎么设计、最容易翻车的超卖和订单状态问题，以及论文和答辩的实操打法，全程只讲干货。

1. 为什么"酒店预定系统"是毕业设计的稳妥之选

先说一个很多人没想明白的问题：毕设选题到底是在选什么？评委看一个毕业设计，核心就四件事——技术栈是不是主流的、功能是不是完整的、你说话的时候能不能讲清楚设计逻辑、以及现场演示的时候系统稳不稳定。至于题目本身新不新颖，重要程度远没有想象中那么高。尤其是"基于SpringBoot的酒店住宿预约系统"这个方向，它之所以每年都有人做、每年都能过，是因为这个业务场景天然覆盖了毕业设计需要展示的所有能力点。

酒店预订的业务链路非常完整，从用户注册登录，到浏览房型、查询可订房间，再到下单、支付、入住登记、退房结算，最后到管理端的订单管理、房态管理、数据统计，这一整条链路包含了Java Web开发里几乎所有核心知识点。更关键的是，这个业务里有订单状态流转、有时间冲突判断、有库存扣减的并发问题，这些才是答辩时能"讲故事"的东西。如果只把系统做成一个躺平版的CRUD，房间里增删改查、订单增删改查，那确实会被老师一句话怼到无言以对。但如果你把订单状态机讲清楚、把并发防超卖的设计说透彻，同一个题目，档次完全不一样。

另外，这个题目的边界非常清晰。相比"校园二手交易平台"这种需要做聊天、做IM的系统，酒店预订系统的业务边界很明确，不会越做越大、最后收不住。单店模型下不需要考虑复杂的跨店结算，也不需要设计分销体系，学习成本和风险都可控。对于大多数需要在有限时间内完成开发和论文写作的应届生而言，这种"有限复杂、可控深入"的题目反而是最优解。

还有一点容易被忽略的是行业认可度。酒店住宿预订服务系统在现实行业里有成熟的对照物，无论是美团、携程还是各大酒店集团的直营系统，核心逻辑都类似。这意味着你在论文里写"本系统参考了行业主流的预订流程设计"是有据可循的，答辩老师不会觉得你在凭空造轮子。而从就业角度讲，你在简历里写"独立完成基于SpringBoot的酒店预订系统设计与实现"，面试官能立刻在脑子里建立画面感，比那些听都没听过的自创项目要容易聊下去。

2. 技术栈选型的底层逻辑：SpringBoot与Java Web生态的取舍

2.1 SpringBoot为什么是毕业设计的绝对主力

技术选型这一步，很多同学容易走两个极端。一个是"我要用最潮的"，一上来就分布式、微服务、Spring Cloud Alibaba、Kafka、Redis Cluster，结果发现自己根本hold不住；另一个是"老师上课教了什么就用什么"，还在抱着SSH（Struts2+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis）的传统组合不放。这两种都不是好选择。SpringBoot是当下的绝对主流，这话一点不夸张。

SpringBoot的核心价值在于它把Spring的配置地狱全部收敛了。以前SSM项目里要写一堆XML配置，配置数据源、配置事务管理器、配置扫描路径、配置视图解析器，光搭环境就能劝退一半人。SpringBoot用自动装配和Starter机制解决了这个问题，你引入一个 spring-boot-starter-web 就拿到了内嵌Tomcat + SpringMVC + Jackson的全套Web开发能力，引入一个 spring-boot-starter-data-jpa 或者配合MyBatis Starter就拿到了持久层能力。开发效率的提升是数量级的。

从毕业设计的角度看，SpringBoot还有一个其他框架替代不了的优势：它在就业市场里的统治地位太稳固了。你打开任何一个招聘软件搜Java后端，十个岗位里至少有八个要求SpringBoot。这意味着毕设选型SpringBoot，你不仅仅是在应付一个学分，而是在提前做就业技能储备。答辩的时候老师问"为什么选这个技术栈"，你可以非常理直气壮地说"这是目前企业级Java开发的主流选择"，这个回答本身就很有说服力。

2.2 Java Web与SpringBoot的关系：别被这两个词绕晕

题目里同时出现了"Java Web"和"SpringBoot"，有些同学会犯迷糊，这俩是什么关系？简单说，Java Web是一个范畴，它指的是所有基于Java技术构建Web应用的开发方式，底层核心是Servlet规范和HTTP协议；而SpringBoot是Java Web领域里目前最主流的开发框架之一，它把Servlet容器（Tomcat）内嵌进来，让你不需要单独部署一个外置的Tomcat就能运行Web应用。

清楚这个关系对答辩很重要，因为老师很可能问："你说是基于Java Web的，那Servlet在你这套系统里体现在哪？"你不能回答"不知道，SpringBoot帮我都处理了"。你要能说出来：SpringBoot的底层就是SpringMVC，而SpringMVC的核心入口DispatcherServlet本质上就是一个Servlet，它负责接收HTTP请求、分发到对应的Controller、再把视图或数据响应给客户端。你的Controller里写的每个接口，最终都是通过Servlet机制在跟浏览器打交道。只需要能把这个链路讲清楚，这个问题就轻松过关了。

2.3 持久层框架：MyBatis、MyBatis-Plus还是JPA

持久层的选型是另外一个必须提前想明白的事。目前主流就三个方向：原生的MyBatis、MyBatis-Plus、Spring Data JPA。给毕业设计的建议是，如果对SQL还比较熟，就用MyBatis-Plus；如果学有余力，想展示一下自己的原生SQL能力，就主用MyBatis-Plus + 手写XML的方式结合。

MyBatis-Plus对毕业设计的价值在于它解决了两个问题：第一，单表CRUD不需要写SQL了，BaseMapper里的insert、selectById、updateById、deleteById直接帮你搞定，开发效率提升明显，你能把省下来的精力放到核心业务逻辑上；第二，它自带分页插件，这对管理端的订单列表、用户列表这种必须分页的场景来说太好用了，不用自己手写LIMIT加总条数查询的繁琐逻辑。

那为什么不直接用JPA？不是说JPA不好，而是对大多数毕设场景来说，JPA的实体关系映射（一对多、多对多）和懒加载机制需要投入更多的学习成本去理解，而且它的复杂查询最终还是要回到JPQL或者原生SQL。一旦你对它理解不透彻，很容易出现懒加载异常、会话关闭之类的玄学问题，在答辩现场翻车就麻烦了。至于纯原生MyBatis，也不是不行，就是单表CRUD要写一大堆几乎一模一样的XML，纯属浪费时间。

2.4 前端方案：前后端分离还是服务端渲染

这个选择题直接决定了你整个项目的工程结构和工作量分配。两条路都有人走，但要结合自己的时间和技术基础来判断。

前后端分离选Vue + SpringBoot，这是当前企业开发的事实标准，Vue负责页面交互和路由，SpringBoot只负责返回JSON数据。这样做的优点是职责清晰，前端页面写起来更灵活，而且答辩的时候你可以说"我的前后端是分离的架构"，这句话的含金量在评委耳朵里是加分的。缺点是你要同时维护两个"项目"，前端要用npm管理依赖，要处理跨域问题（CORS），要学习Vue的路由、状态管理、Axios请求封装，学习曲线是实打实的。如果你前端基础比较薄弱，走这条路一定要预留出足够的时间。

用Thymeleaf做服务端渲染，本质上是在HTML模板里写th:each、th:if这样的语法，通过Controller返回ModelAndView渲染页面，SpringBoot原生支持，配置简单，调试也直观。这套方案最大的优势是不用搭建前端工程，开发思路和后端页面混编时代的传统Java Web完全一致，非常容易上手。缺点也很明显，页面复杂的时候前端逻辑写起来很痛苦，而且"前后端分离"这个常见加分项你就没有了。

我的建议是：如果你从大二就开始接触Vue，有一定基础，那就大胆走前后端分离；如果你Java都还没学明白，前端只会一点HTML和CSS，那老老实实用Thymeleaf，起码能保证项目能按时交付。记住，毕业设计的第一目标永远是"完整可运行"，技术炫不炫酷是第二位的。

2.5 环境版本搭配：一个最容易踩坑但没人提醒的细节

技术选型的最后，强烈建议把环境版本固定下来。很多同学的开发环境一团乱麻，JDK装了不知道几个版本，MySQL是5.7还是8.0也说不清，SpringBoot版本更是凭感觉新建项目时选的。这些细节看着不起眼，但到了部署演示和写论文的时候就全成了坑。

给一个经过多次验证的稳定组合：JDK 8或JDK 11 + SpringBoot 2.7.x + MyBatis-Plus 3.5.x + MySQL 8.0 + Maven 3.8+，如果是前后端分离再加Vue 2或Vue 3配Element UI。为什么不建议JDK 17和SpringBoot 3.x？因为SpringBoot 3基于Jakarta EE，很多第三方组件的兼容性还在磨合中，网上能查到的踩坑案例也远不如2.7丰富。作为一个要赶时间交毕设的项目，稳定压倒一切，用足够成熟的版本组合才是对自己负责。SpringBoot 2.7.18是2.x系列的最后一个版本，修复了大量已知问题，用它作为毕业设计的技术底座非常合适。

3. 核心业务模型与数据库设计的完整拆解

3.1 数据库表设计：没有一张表是多余的

数据库设计是整篇毕业设计的骨架，后端的Controller、Service、Mapper都是在为这些表服务。酒店预定系统从单店模型出发，最少需要六张核心表，每一张都有自己的职责，我逐个说清楚。

• 用户表（t_user）：用户编号、用户名、密码（必须加密存储）、真实姓名、手机号、身份证号、角色类型（区分普通用户和管理员）、注册时间。这里要注意角色字段的设计，毕业设计用tinyint类型存0和1就够，0代表普通用户，1代表管理员，不要在角色上设计复杂的权限表结构，那是企业级微服务权限系统才需要考虑的。

• 房型表（t_room_type）：房型编号、房型名称（大床房/双床房/家庭房/套房）、房间面积、床型描述、可住人数、挂牌价、门市价、早餐数量、房间图片地址、房型描述。房型和房间必须分成两张表，这是很多新手容易犯的错误——直接做一张"房间表"，把"XX酒店XX楼层XX号房，属于大床房"这种信息全塞进去，导致同一个房型的多个房间要重复存储大量相同属性，数据冗余不说，以后想统一调价也特别麻烦。

• 房间表（t_room）：房间编号、所属房型编号（外键）、房间号、楼层、朝向、当前状态（可用/打扫中/维修中）。这张表代表物理存在的每一个具体房间，它跟房型表是多对一的关系。房态查询本质上就是在查这张表里有哪些房间处于可用状态。

• 订单表（t_order）：订单编号、用户编号（外键）、房型编号（外键）、房间编号（外键，可以在分配房间时再填）、入住日期、退房日期、预订间数、订单金额、折扣金额、实付金额、支付方式、订单状态、下单时间、支付时间、入住人姓名、入住人手机号、入住人身份证号、备注。这张表是整个系统里字段最多的表，也是业务逻辑最重的表，我后面单开一章讲它。

• 入住登记表（t_checkin）：登记编号、订单编号、房间编号、入住人姓名、证件号、入住时间、退房时间、押金金额。虽然订单表里已经有入住人的信息，但把入住登记单独拆出来会让后续扩展更方便，比如一个订单可以登记多个入住人，这在做节假日团体入住场景时很自然。

• 操作日志表（t_operation_log）：日志编号、操作用户、操作类型、操作描述、操作时间、IP地址。这张表的存在主要是给管理端展示最近操作记录用的，同时作为"系统具备审计能力"的证明，答辩时是一个细节亮点。

除了这六张表，如果还需要做数据统计图表，可以额外考虑一张订单统计视图，直接用SQL聚合生成，不需要物理建表。

3.2 订单金额为什么用Decimal而不是double

这是一个答辩高频考点，也是开发中特别容易埋雷的地方。很多同学在设计订单表的时候，金额字段直接用double类型就上了，联想起"反正Java里也有Double"。但做金融和交易相关的东西，用浮点数表示金额是行业大忌。原因在于计算机用二进制存储浮点数时存在精度误差，0.1 + 0.2在Java里算出来是0.30000000000000004，这在金额计算这种场景下绝不能接受。

正确的做法是在数据库层面用DECIMAL(10, 2)，在Java实体类里用BigDecimal。这样价格计算时就不会出现浮点精度问题。先后端连数据库，Engine都用对，金额计算全链路都是精度可控的。这个字段设计理念一定要写进论文里，属于"考虑了实际业务风险"的加分项。

3.3 可订房查询的核心SQL：时间冲突判断

如果你做的只是"房型列表展示加一个下单"，那系统确实很浅。真正有点技术含量的地方在于：用户选择入住日期和离店日期以后，你得告诉他这个时间段还有没有房间可订。这个逻辑的SQL怎么写，就是判断一个房间是否在目标时间段内存在重叠的订单。

简单说，如果一个房间在"目标入住日期"到"目标离店日期"之间有任何一笔有效订单（已支付或者已完成入住），那这个房间在这个时间段就不可订。判断两条时间区间重叠的条件是：新入住的开始时间 < 已有订单的结束时间 且 新退房的时间 > 已有订单的开始时间。这是一个经典的时间区间重叠判断公式，把它翻译成SQL的where条件就是：

WHERE room_id = #{roomId} AND status IN ('PAID', 'CHECKED_IN') AND checkin_date < #{targetCheckoutDate} AND checkout_date > #{targetCheckinDate}

如果查询结果集非空，说明这个房间在目标时间段内已经被占了。查询所有可订房间的完整逻辑就是：在某个房型下，找到所有状态为"可用"的房间，并且这些房间在目标时间段内不存在上面这个条件能命中的订单。理解了这个SQL，你再去实现房态日历、批量预订这些功能就会顺很多。

4. 订单状态机与并发防超卖：全系统最容易翻车的地方

4.1 订单状态怎么设计才经得起追问

订单这个对象，最核心的其实是它的状态字段。我在评审毕业设计时见过太多"订单只有两个状态——未支付和已支付"的设计，这种单薄的业务逻辑一旦遇到"取消订单""超时关闭""退款"等场景就完全没法扩展了。一个能让答辩老师认可的订单状态机，至少要覆盖如下几种状态：

• 待支付（PENDING）：订单创建成功，但用户还没完成支付；
• 已支付（PAID）：用户支付成功，可以在入住时间到达后办理入住；
• 已入住（CHECKED_IN）：用户到达酒店，完成登记，房间已占用；
• 已退房（CHECKED_OUT）：用户完成退房，房间释放，订单流程基本结束；
• 已取消（CANCELLED）：用户在支付前主动取消订单；
• 已关闭（CLOSED）：订单待支付超时被系统自动关闭，或者已支付订单发生全额退款后关闭。

更精细的业务里还可以加"待评价"状态，但那属于OTA平台的玩法，毕业设计做上面六种状态已经非常完整。状态之间的流转是有严格方向的，不是任何状态都能跳转到任意状态。比如，已入住订单不能直接跳到支付前的那种"已取消"，因为钱都已经收了。核心流转路径是：待支付→已支付→已入住→已退房；待支付→已取消；待支付→已关闭；已支付→已关闭（退款路径）。你把这个流转图画清楚，放在论文里，没有老师能说你的业务做得浅。

4.2 超卖问题：预定的"双人抢房"竞态

超卖是秒杀系统和预订系统里最经典的问题。放到酒店预订场景里就是一句话：两个用户同时看中了同一间房，并且同时下单，系统必须保证只有一个能预订成功，另一个要么遗憾地看到"手慢无"，要么被引导到其他房间。如果代码写得不对，两个人都下单成功了，到酒店发现只有一间房，就是事故。

出现超卖的根本原因是并发下的竞态条件。假设代码这样写：

1. 查询房间状态，发现是"可用"；
2. 创建订单；
3. 更新房间状态为"已占用"。

这段逻辑在并发情况下，如果两个请求同时执行了第一步，都读到"可用"，就会同时往下走，最后都下单成功。要解决这个问题，就要在关键步骤上做并发控制。毕业设计场景下最实用的方案有两种。

方案一：添加状态更新条件（乐观锁思路）。在扣减房间状态时，把SQL写成"要求当前状态必须还是可用"：

UPDATE t_room SET status = 'OCCUPIED' WHERE room_id = #{roomId} AND status = 'AVAILABLE';

这条UPDATE语句如果影响行数为1，说明抢房成功；如果影响行数为0，说明房间状态已经被人改了，下单失败。这个做法不需要引入任何额外组件，一行SQL就解决了并发竞态问题，而且可以在答辩现场直接口述"我通过条件更新来保证并发安全"，说服力很强。

方案二：数据库唯一约束/分布式锁。可以在订单表里对"房间号+入住日期+退房日期"建立唯一约束，从数据库层面硬性保证同一房间同一时间段只能有一条有效订单。这个方案的安全性更高，但如果订单里的入住日期被用户反复修改，唯一约束需要跟着调整，实现稍显繁琐。至于Redis分布式锁，写论文提一句"生产级方案可以使用Redis实现分布式锁，但本系统基于单机架构采用乐观锁已能满足需求"即可，没必要为了展示技术而给自己挖坑。

4.3 未支付订单的自动关闭：Spring Schedule的正确用法

酒店预订场景里，用户下单后不支付、把房间"占着茅坑"是常有的事。真实业务里平台会把订单保留15到30分钟，超时未支付就自动关闭，把房间释放出来给别人预订。毕业设计里这个功能用Spring自带的定时任务就能实现，不需要引入Quartz。

实现思路是，在项目启动类上开启@EnableScheduling，然后写一个定时任务类，每隔一分钟扫描一次订单表，把状态为"待支付"且创建时间距今超过15分钟的订单批量修改为"已关闭"。核心代码示意如下：

@Component public class OrderTimeoutTask { @Autowired private OrderMapper orderMapper; @Scheduled(cron = "0 */1 * * * ?") public void closeExpiredOrders() { // 计算15分钟前的截止时间，把待支付超时订单批量更新为已关闭 orderMapper.closeOverdueOrders(LocalDateTime.now().minusMinutes(15)); } }

这个功能有几个细节要注意。一是定时任务的执行周期不需要设得太密，1分钟一次足够；二是超时订单关闭后，如果涉及已支付的退款操作要慎重，这属于逆向流程；三是单机定时任务在集群部署下会重复执行，所以语句要写成"受影响行数"判断的幂等操作，重复执行也不会出大问题。把这个功能写进论文里，作为"考虑了用户体验和资源利用"的亮点，答辩时提一句，老师基本都认可。

4.4 退款与取消：最容易想当然的业务逻辑

已支付订单的退款，是毕业设计里最容易被做成"把订单状态改成已退款就完了"的地方。真实逻辑没有那么简单：退款要生成退款记录，订单状态要改变，资金流水要有迹可循。如果做的是模拟支付（本地模拟或者沙箱支付），退款流程至少应该是：

1. 创建退款记录，记录原订单号、退款金额、退款原因；
2. 调用支付平台的退款接口（模拟环境就模拟返回退款成功）；
3. 更新原订单状态为"已关闭"；
4. 更新房间状态为"可用"。

特别要注意房间释放这个动作。无论订单是取消、超时关闭还是退款完成，只要这个订单不再占用房间了，对应的房间状态就必须释放回来。我在实际评审项目时，见过不少同学订单取消功能做了，但房间状态忘了更新，导致用户取消订单后这间房永远不可订。这种低级错误，一旦演示时被老师随手动一下就能发现，非常减分。

5. 三个能拉开差距的进阶功能设计

到这里，整个系统已经具备"完整可用"的底子了。但如果你的毕设想拿高分甚至冲击优秀，光有CRUD和订单流转还不够，还需要几个能让评委眼前一亮的功能。

5.1 管理端数据看板：用图表说话

管理端首页放一个大屏看板，上面展示今日订单数、今日营业额、在住房间数、入住率、近7日营收折线图、房型预订占比饼图，这个功能做出来，你整个系统的"观感"会立刻上一个档次。数据看板的价值在于把之前所有业务表的数据通过聚合查询变成可视化的经营指标，完全吻合题目里"数字化订房管理平台"的定位。

技术实现上，前端可以用ECharts（一个非常成熟的JavaScript图表库），后端只需要提供几个聚合查询接口。比如近7日营收曲线，就是按日期分组统计已支付订单的日销售额；房型预订占比则是按房型分组统计订单量。这些聚合查询用MyBatis-Plus的分组查询或者手写几条带GROUP BY的SQL就能完成，工作量不大，但展示效果极好，答辩现场打开看板的一瞬间基本就能镇住场。

5.2 完整的多条件组合搜索

管理端的订单列表，不能只是简单做个分页就完了。一个"能用"的后台管理列表，至少要支持按订单号搜索、按下单时间范围筛选、按订单状态筛选、按用户手机号搜索，而且这些条件要能自由组合。这里面就涉及MyBatis动态SQL的使用了，也就是用 标签和 标签拼装查询条件。这个技能点本身就很有含金量，能体现你对SQL和持久层框架的掌握程度。在论文里把动态SQL的实现方式写一段，配上"通过动态SQL实现灵活的查询组合"的说明，这是很加分的。

5.3 全局异常处理与参数校验

很多同学的代码里，校验参数靠手动if，异常抛出后就剩下一大串Tomcat默认的错误页面，不仅难看还暴露内部信息。正确的做法是统一使用Spring的全局异常处理机制：写一个全局异常处理器，用@RestControllerAdvice捕获各类异常，然后统一封装成JSON格式的错误响应给前端。参数校验尽量用JSR 303注解（@NotNull、@NotBlank、@Min等），配合@Validated在Controller层快速完成字段校验。

这套设计的意义在于，系统向外部暴露的所有错误信息都是可控的、结构化的，而不是随机的异常堆栈。在答辩时你只需要说一句"我的系统对所有异常做了统一处理，保证接口返回格式的一致性"，这就展示了你对工程质量的理解，立刻和那些"能跑就行"的选手拉开差距。

6. 部署上线与论文撰写的实战打法

6.1 打包部署：用jar还是war，Docker要不要上

SpringBoot最爽的地方就是内置了Tomcat，所以打包直接用maven打成可执行jar包就行，部署命令就是一条：

java -jar hotel-system.jar --spring.profiles.active=prod

不再需要像传统Java Web项目那样手动下载Tomcat、把war包扔到webapps目录下面再启动，这个体验是时代级的进步。如果你有余力，可以再学一点Docker，写一个简单的Dockerfile把项目打成镜像，用docker-compose编排MySQL和应用的启动。要知道在2024年这个时间节点，容器化部署已经是后端开发的标配技能，写进简历也是加分项。但说实话，毕业设计展示阶段用java -jar原地启动，服务器上运行效果完全一样，Docker是可选项。

6.2 演示环境里的配置困境与破解

我每年都会见到答辩前夜在酒店房间或者机房演示时，因为环境问题翻车的案例。最典型的坑有两个：第一个是项目里的数据库连接配置写的是localhost，跑到演示那台机器上就连不上自己的数据库；第二个是配置文件里的端口号被别的进程占用了，启动直接报错。

破解方法是提前做配置分离。在SpringBoot的application.yml里分三层放：公共配置放一份，dev环境一份，prod环境一份，用spring.profiles.active来切换。数据库连接、Redis地址这些敏感信息放各自的profile文件里，写死成部署时的目标机器地址。演示前一天，一定用一台"干净"的机器完整走一遍从环境安装到启动的所有流程，包括JDK装没装、MySQL启动没启动、数据库脚本导没导、前端资源打没打包，别把第一次完整演示留到答辩现场。这个习惯本身，就是很多大厂项目上线前要做"彩排"的原因——提前暴露所有能暴露的问题。

6.3 论文写作的核心思路：工作量和深度要双在线

写论文这块，我见过两种极端。一种是事无巨细，把页面截图贴了几十张，整篇论文像产品说明书，毫无技术深度；另一种是浓墨重彩讲需求分析和研究背景，但核心设计和技术难点部分写得特别单薄。这两种都拿不了高分。

正确做法是：需求分析部分简洁清晰，用用例图加文字把核心角色和操作流程讲清楚即可；技术路线部分要"少而透"，选择1到2个能体现你水平的技术点重点展开。比如你选择了"并发防超卖设计""订单状态机与超时关闭机制"作为重点章节，那就要把设计思路、代码实现、测试过程、遇到的问题和解决方案写透，而不是把每个功能模块都蜻蜓点水地过一遍。答辩老师翻论文时看到的是"能就一个技术问题深入到代码级"，比看到"页页都像截图说明书"要对味得多。

6.4 答辩现场的问与答：从被问到引导

答辩环节本质上是向评委展示你的思考过程，而不是单纯的问答撞车。既然知道评委大概率会问"为什么用SpringBoot""超卖你怎么解决的""下单流程里事务怎么控制"，那你在讲系统演示的时候就可以主动把节奏带过去。演示到下单环节时，顺嘴说一句"这里我做了并发控制，后面可以展示压测效果"，老师的注意力就会顺着往你准备充分的深水区走。提前准备一份可能被问到的问题清单，结合自己的系统把答案写出来，每条控制在3到5句话，重点讲清楚"我遇到什么问题、怎么解决、为什么这样解决"，这套逻辑一顺，答辩基本不会出大状况。注意事务这块也要补一下，因为订单创建、房间状态更新、日志写入这三个操作必须在一个事务里，否则任何一个环节失败都会造成数据不一致，这大概率会被单独点到。

最后的几点实在话

回头看一下，SpringBoot酒店预定系统这个毕业设计，技术难度不属于"天花板"级别，但要做到"高分优秀"，靠的是把每一个环节都做到位：数据库设计要经得起推敲，订单状态和并发防超卖要真正理解，进阶功能要能体现实实在在的开发功底，论文和答辩要有逻辑有重点。我见过不少选了这个题目的学生，最后靠这一个项目在实习面试里聊了半个多小时，因为他对每一张表、每一个状态、每一个异常分支都了然于胸。这其实印证了一件事：毕业设计的价值，不在于题目有多花哨，而在于你在这个过程中建立了"从需求到设计再到实现"的完整闭环能力。把这个能力练到手，这一年的设计做得就值。