Spring Boot酒店预定系统毕业设计：从技术选型到部署答辩全解析

这一期记录一个完整的Spring Boot酒店预定系统毕业设计项目。无论你是自己开题，还是在GitHub / 开源社区找参考源码准备二次开发，这篇内容都会围绕项目本身，从选题逻辑、技术架构、数据库设计、后端核心功能、前端对接，一直讲到打包部署和答辩准备。写这篇文章之前，我特意把近期搜索热度比较高的几个话题也一并看了下，包括"Spring Boot版本太高怎么选""JDK 1.8能不能打包到Docker Desktop""Spring Boot自动装配原理"这类问题，后续都会结合具体场景给出参考思路。

1. 酒店预定系统这个题目为什么值得做

1.1 一个题目串起Web开发三大核心能力

计算机毕业设计最怕的是题目太空或者太大。太空的题目做到最后发现没什么可写的，页面加上增删改查就凑不出内容了；太大的题目比如"智慧酒店管理平台"，光是一个物联网对接和设备管理就能拖垮整个毕设进度。而"酒店便捷预定系统"刚好处于一个比较舒服的区间，它既有完整的用户端行为链路，又有典型的管理端操作场景，还天然涵盖了Web开发中最核心的三块知识。

第一块是数据库建模。酒店预定不是简单的单表CRUD，它涉及用户、房间、房型、订单、支付记录、评价等多个实体，而且订单和房间之间存在明显的状态联动：房间有"可订/已订/清洁中"等状态，订单有"待支付/已确认/已入住/已退房/已取消"等状态。把这些状态的关系设计清楚，整个项目的核心就已经撑起来了。

第二块是后端接口设计。预定系统的接口天然带着业务复杂性，比如按日期查询可订房间、订单创建时的库存扣减、超时未支付订单的自动取消。这些业务逻辑比教科书上的"用户管理""新闻发布"要更有含金量，写进毕业论文里也更好展开论述。

第三块是前端交互。用户端需要一个清晰的下单流程：选日期、选房型、填写入住人、提交订单、支付查看订单状态；管理端需要房间管理、订单管理、数据概览等页面。前后端分离模式下，接口联调和权限控制也都能在这个项目里得到完整的训练。

所以这个题目非常适合作为计算机科学与技术、软件工程、信息管理等专业的毕业设计选题，它难度适中、工作量可度量、技术栈通用，而且能够清晰地向评委展示你具备独立完成一个业务闭环项目的能力。

1.2 系统角色与核心需求拆解

整个系统的角色划分要尽量贴近真实酒店业务，但不能把真实酒店管理系统里所有功能都搬过来。对于一个毕业设计来说，角色控制在三类左右最为合适。

• 游客用户：浏览酒店信息和房间信息，注册账号、登录系统。
• 注册用户：在线搜索房间、下单、支付、查看订单、取消订单、发表评价。
• 系统管理员：管理房间信息、房型信息、订单状态、用户账号、系统公告和基础数据统计。

围绕这三个角色，核心的业务需求可以拆成四个模块。用户模块解决的是"我是谁"的问题，设计注册、登录、个人信息维护；房间模块解决的是"有什么可订"的问题，设计房型分类、房间列表、房间状态管理；订单模块解决"怎么订、怎么取消"的问题，这是整个系统的业务核心，涉及订单创建、支付状态更新、入住退房流程以及超时取消；统计模块解决"酒店经营得怎么样"的问题，设计订单量统计、房间入住率统计等简单图表。

1.3 功能边界的取舍原则

许多同学做毕设失败不是因为做得太少，而是因为想做太多。关于功能边界，我的个人建议是守住两条底线：第一，核心业务闭环必须完整，用户从注册、检索、下单到支付、评价这条链路不能断；第二，非核心功能尽量做深度而不是做广度，比如支付功能不需要真的对接微信支付或支付宝，用"模拟支付"的方式在订单状态上做状态流转完全可以，重点把订单状态的迁移逻辑写得严谨。

2. 技术选型与工程初始化：基于Spring Boot搭建前后端分离骨架

2.1 技术栈选型背景

现在的毕业设计项目，主流的架构方案基本是Spring Boot + Vue的前后端分离模式。这类方案之所以流行，是因为它既贴近企业开发真实场景，又便于分工和模块化管理。如果你的基础较弱，也可以选择Spring Boot + Thymeleaf服务端渲染的方案，开发效率高、代码量少、容易把控，但论文的内容量和代码的可展示性会弱一些。

我接手维护这套"Spring Boot酒店便捷预定系统"源码时，后端是Spring Boot，前端是Vue + Element UI，数据库使用MySQL，鉴权使用JWT + Spring Security。这套组合的可替换性很强：如果你不熟悉Spring Security，可以换成拦截器加JWT的手动鉴权方案；如果前端不想写Vue，也可以直接用模板引擎。但本篇文章先按前后端分离这套主流方案来讲，其中涉及的接口设计、表结构和后端逻辑，无论前端怎么做都是通用的。

2.2 Spring Boot版本选型细节

搜索热度里有一条"springboot版本太高"的反馈，这个确实是近几年毕业设计项目最常见的坑。以Spring Boot官方目前的情况来看，3.x系列是主流，但它强制要求JDK 17以上，并且部分第三方框架（尤其是一些老牌国产工具包和代码生成器）的兼容还没完全跟上。

这里我特别说明一下：如果这套酒店预定系统你想要跑在JDK 8环境下，那么建议选择Spring Boot 2.7.x系列中的最新版本；如果坚持用Spring Boot 3.x，那么会连带地要求Spring Security 6.x、JWT相关库的版本调整等，改动量不小，而且网上大量2.x时代的老教程会失去参考价值。

以下是我整理的一个选型对照表：

对于大多数计算机毕业设计来说，我强烈建议选方案A。原因很简单：JDK 8 + Spring Boot 2.7是过去几年积累资料最丰富、踩坑答案最齐全的组合。等系统跑通、论文写完、答辩通过之后，再研究升级到Spring Boot 3.x也不迟。

2.3 Maven工程结构与多环境配置

拿到源码后，第一步是调整工程结构。一个合理的Maven工程结构，包名规则建议是com.xxx.hotel，下面按功能模块分包，注意要控制包之间的依赖方向，避免循环依赖——这个话题在Spring Boot面试和答辩中经常被问到，后面我会单独讲。

code复制com.example.hotel
├── HotelApplication.java
├── config          // 配置类：CORS、Security、MyBatis-Plus
├── controller      // 接口层：接收请求、返回结果
├── service         // 业务层：核心业务逻辑
│   └── impl
├── mapper          // 数据访问层：MyBatis-Plus的Mapper接口
├── entity          // 数据库实体类
├── dto             // 前端交互数据传输对象
├── vo              // 视图对象，如订单详情返回体
├── common          // 通用类：常量、枚举、统一返回结构
├── exception       // 全局异常处理
└── utils           // JWT工具类、日期工具类等

application.yml建议做多环境配置，拆分成application-dev.yml和application-prod.yml。开发阶段数据库连接本地，生产阶段连接云服务器或Docker容器。配置分离的逻辑在答辩时也是一个可说点，它体现了工程化思维。

2.4 初始依赖的注意事项

如果你的Spring Boot版本在2.7及以上，还要注意Maven依赖中加上sprint-boot-starter-validation（参数校验）、spring-boot-starter-data-redis（如果做缓存）的版本管理。这些依赖本身不难，难的是版本冲突，常见格式是：

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
    <relativePath/>
</parent>

只要依赖了Spring Boot的parent父工程，绝大多数常用依赖的版本Spring Boot已经帮你管理好了，不需要手动写<version>。如果发现某个第三方库的版本冲突，先不要急着手动指定版本号，优先查一下是否缺少排除项。

3. 数据库建模：房间、用户、订单三张核心表的设计逻辑

3.1 实体关系梳理

酒店预定系统的实体关系并不复杂，核心可以概括成：用户角色之间是普通注册与管理员的关系，房型与房间是一对多关系，用户与订单是一对多关系，订单与房间是多对一关系。画出ER图后你会发现，真正的设计难点其实集中在两张表上：房间表和订单表。

以数据库设计的常见范式来看，如果一张订单表里既存用户信息又存房间信息还存房型信息，那必然是冗余度太高；但反过来，如果字段拆分过细导致查询一次订单详情要关联四五张表，那也会带来严重的性能问题。合理的做法是中间态设计：订单表保存必要的冗余字段，比如用户名、房型名、房间号、单价，这是为了方便订单列表页展示，但订单与用户、房间之间仍然保留主外键关系，便于追踪数据血缘。

3.2 房型表与房间表的具体字段设计

房型表和房间表是最容易混淆的一对概念。房型是"产品"概念，表示大床房、双床房、套房这些分类，包含房型名称、面积、床型、朝向、设施、价格、图片等属性；房间是"库存实例"概念，表示具体的物理房间，比如"302号大床房"，包含房间编号、所属房型、楼层、房间状态。

两张表关联后，价格跟着房型走，状态跟着房间走，这在业务上是说得通的。设计表的时候有一个容易忽略的细节：房价通常会随时间变化，促销价、节假日价是真实酒店业务的刚需。如果要做完整，可以再设计一张房价日历表，以"房型ID + 日期 + 价格"为维度。不过对于毕业设计，在房型表中预留一个price字段，用简单的算法做价格计算就够了，不必把整个房价策略系统搬进来。

3.3 订单状态机：一张表如何撑起整个业务流程

订单表是酒店预定系统的业务中枢，也是论文中"系统设计"部分最有话可讲的模块。订单状态我建议这样设计：

订单状态机设计的关键在于"谁能改变状态"以及"什么条件触发状态改变"。比如待支付状态下用户可以直接取消；已支付状态下用户取消则涉及退款逻辑（毕设中可以简化成直接取消）；已入住状态下不能再取消；已退房状态后才可以评价。把这些约束写清楚，代码中的if/else判断就有了依据，不至于到写代码的时候想到哪写到哪。

3.4 可订房间查询的SQL核心逻辑

"根据日期区间查询可订房间"是酒店预定系统里技术要求最高的一条SQL。基本思路是：找出指定日期区间内与订单表有重叠的房型记录，再排除这些已被占用的房间，剩下的就是可订房间。

sql复制SELECT r.*, t.name AS type_name, t.price
FROM room r
LEFT JOIN room_type t ON r.type_id = t.id
WHERE r.status = 0
AND r.type_id = #{typeId}
AND r.id NOT IN (
    SELECT o.room_id FROM orders o
    WHERE o.status IN (1, 2)
    AND o.check_in_date < #{checkOutDate}
    AND o.check_out_date > #{checkInDate}
)

这段SQL的日期重叠判断条件是很多初学者最容易写错的地方：判断两段日期区间是否有重叠，不是简单的大于小于，而是"现有订单的入住日期 < 新订单的离店日期 并且 现有订单的离店日期 > 新订单的入住日期"。这个交集判断是倒过来的，理解它，你的可订房间查询就不会出逻辑漏洞。

4. 后端核心功能实现：从登录鉴权到订单流转

4.1 基于JWT的登录鉴权与ThreadLocal用户上下文

用户登录模块，我用的是JWT（JSON Web Token）方案。对比Session方案，JWT的后端不需要存储会话状态，适合前后端分离场景，也方便在答辩时解释"无状态服务"这个概念。

JWT实现的核心步骤非常清晰：登录成功后，后端生成一个token返回给前端；前端后续请求在请求头中携带Authorization: Bearer <token>；后端通过拦截器或Spring Security过滤器校验token，解析出用户ID和角色；再把用户信息放到一个静态工具类中，方便Service层获取当前登录用户。

这里有一个细节值得展开——ThreadLocal的使用。每次请求进来时把解析出的用户对象放入ThreadLocal，请求结束时记得移除，否则在高并发场景下可能会出现数据串号问题。这个细节虽然在毕业设计的并发量级下几乎不可能暴露，但写到论文中会让系统设计显得严谨。

4.2 Spring Security与RBAC权限控制

使用Spring Security时，一个容易陷入困境的点是"版本带来的配置差异"。Spring Security 5.x时代用WebSecurityConfigurerAdapter，到了Spring Security 6.x时代，这个类被废弃了，改成了SecurityFilterChain的Bean配置方式。如果你用Spring Boot 2.7.x，下面的配置代码可以直接参考；如果是Spring Boot 3.x，就要注意用新写法。

java复制@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf().disable()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            .and()
            .authorizeRequests()
            .antMatchers("/api/auth/login", "/api/auth/register", "/api/hotel/**").permitAll()
            .antMatchers("/api/admin/**").hasRole("ADMIN")
            .anyRequest().authenticated()
            .and()
            .exceptionHandling().authenticationEntryPoint(unauthorizedHandler);
        http.addFilterBefore(jwtAuthenticationTokenFilter(), UsernamePasswordAuthenticationFilter.class);
        return http.build();
    }
}

antMatchers的路径匹配规则是权限控制的灵魂。前端所有的公开接口（注册、登录、浏览房间信息）放行；管理端关键操作（房间管理、订单管理、用户管理）限制为管理员角色；其余接口要求登录。这样设计后，整个系统的权限边界就清晰了。

4.3 订单创建的幂等性与房间库存扣减

订单创建有两个经典问题：重复提交和超卖。重复提交是指用户快速点击两次"提交订单"按钮，导致生成两笔一模一样的订单；超卖是指同一时间段内同一间房被卖给了两拨不同的人。

重复提交的解决方案是在前端做按钮防抖，同时后端在创建订单前校验"该用户在该时间段内是否已有有效订单"，如果存在，直接拒绝。这个校验逻辑用一个联合查询就能完成。

超卖问题的根源在于"查询房间状态和插入订单"不是原子操作。解决的思路有两种：第一种是加数据库行锁，SELECT ... FOR UPDATE，这个能保证同一时间只有一个事务在处理同一房间，但并发能力会下降；第二种是利用数据库乐观锁，在房间表增加版本号字段，更新时检查版本号是否一致，不一致则说明被别人改过，重新查询。毕设项目推荐用FOR UPDATE方案，实现直观且容易讲解。

4.4 定时任务：超时未支付订单自动取消

订单的自动取消功能，我选择Spring Boot内置的@Scheduled定时任务来实现，配合Quartz可以做更复杂的任务调度。热搜词里有"springboot quartz"，这里我把两个方案对比一下：@Scheduled适合周期固定、逻辑简单的任务；Quartz支持cron表达式、持久化、集群部署，适合任务量大、需要高可用的场景。

毕设中的定时取消订单用@Scheduled就够了。实现逻辑是每隔一段时间扫描订单表，找出状态为"待支付"且创建时间超过15分钟的订单，将其状态改为"已取消"，同时释放房间占用。注意扫描的时间间隔不要设置成1秒，建议30秒或1分钟，数据库压力会小很多。

java复制@Scheduled(fixedDelay = 60000)
public void autoCancelExpiredOrders() {
    LocalDateTime expireTime = LocalDateTime.now().minusMinutes(15);
    List<Orders> expiredOrders = ordersMapper.selectList(new LambdaQueryWrapper<Orders>()
        .eq(Orders::getStatus, 0)
        .lt(Orders::getCreateTime, expireTime));
    for (Orders order : expiredOrders) {
        order.setStatus(4);  // 取消
        ordersMapper.updateById(order);
        // 释放对应房间状态
    }
}

这类定时任务写到论文里，还应该补充一个"为什么不直接用Redis过期时间"的分析：Redis TTL虽然处理单个key过期很方便，但过期后要触发回调并更新数据库，需要额外引入监听机制，逻辑并不比定时扫表简单；而且数据库表的订单记录仍然保留，便于对账，这是业务上的一种权衡。

4.5 循环依赖问题的根因与规避

搜索热词里出现了"springboot 循环依赖"，这个我得多说一句，因为很多同学在毕设答辩前都容易在这个问题上翻车。

循环依赖简单说就是A依赖B、B又依赖A。Spring Boot 2.6版本之前，默认允许循环依赖，Spring通过三级缓存机制进行解决；2.6版本之后，官方默认禁止了循环依赖，项目启动直接报错，提示"Requested bean is currently in creation"这类信息。

毕业设计项目中，循环依赖通常不是刻意设计的，而是写Service代码时没有注意层次关系导致的，比如OrderService里面注入了UserService，同时UserService里面又注入了OrderService。

对待循环依赖的正确态度不是去找@Lazy注解或者setter注入来绕过报错，而是应该重新审视代码结构，把互相依赖的公共逻辑下沉到一个新的Service中。这样既解决了运行问题，又优化了代码结构——这个优化动作写进论文的"系统改进"部分，是非常加分的。

5. 前端页面与接口对接：Vue + Element UI的实际落地

5.1 Vue工程结构与项目初始化

前端部分是很多做后端方向的同学的痛点，但不要焦虑，酒店预定系统的前端页面数量适中，而且大部分是列表页和表单页，套用Element UI组件库可以快速完成。

前端工程推荐用Vue CLI或Vite创建。如果你是Vue 2 + Element UI组合，相对稳定；如果选择Vue 3，则对应组件库是Element Plus，API上有一些变动。这里有一个选型建议：如果你的Spring Boot版本是2.7.x，且你只熟悉Vue 2，那前端就坚持Vue 2；不要一味追求版本新，够用就好。

5.2 Axios封装与请求拦截器

前后端分离项目里，前端与后端的沟通完全依赖Axios。一个规范的Axios封装应该包含：请求基准地址配置、请求头携带Token、统一处理响应状态码、全局响应拦截处理401跳转登录页、错误信息提示。

下面是一个精简的路由和请求拦截示意：

javascript复制service.interceptors.request.use(
  config => {
    const token = localStorage.getItem('token');
    if (token) {
      config.headers['Authorization'] = 'Bearer ' + token;
    }
    return config;
  },
  error => Promise.reject(error)
);

service.interceptors.response.use(
  response => {
    const res = response.data;
    if (res.code !== 200) {
      Message.error(res.message || '请求失败');
      return Promise.reject(new Error(res.message));
    }
    return res;
  },
  error => {
    if (error.response && error.response.status === 401) {
      router.push('/login');
    }
    return Promise.reject(error);
  }
);

在对接接口时，建议前后端先约定一份统一的返回结构，例如：

json复制{
  "code": 200,
  "message": "success",
  "data": {}
}

这样前端在处理响应时只需要关心data字段，而业务异常统一抛给全局异常处理器返回。这套返回结构在后端有一个对应的Result<T>类，每个Controller的返回值都包装成它，前后端开发就可以并行推进，不用等接口联调时再对字段。

5.3 核心页面设计：房间列表、订单提交、管理后台

用户端最重要的一张页面是房间列表页。它包含三个关键部分：搜索条件区（入住日期、退房日期、房型、价格区间）、房间卡片列表、预订按钮和楼层分布展示。这里的核心是与后端"可订房间查询"接口的数据配合：前端把用户选择的日期传到后端，后端返回该时间段内所有可订房间，前端渲染卡片时再标记"已满"或"不可订"的样式。

订单提交页则要处理一段完整的数据拼装：用户信息、房间信息、入住离店日期、预计价格（由后端计算）、入住人姓名和手机号、备注。前端只做表单校验和提交，价格计算建议放在后端——这样价格规则变了前端不用改，论文设计上也更合理。

管理端方面，房间管理用表格展示房间号、房型、楼层、状态、操作按钮，房间状态支持"空闲/占用/清洁"切换；订单管理使用带标签的表格展示订单编号、用户、房型、入住离店时间、金额、状态，状态变化能通过下拉选择直接修改；数据概览用卡片展示今日订单量、本月营业额、房间入住率，配合ECharts图表展示近一周订单趋势。

6. 单元测试与接口调试：提交答辩前的质量保障

6.1 测试意识：毕设中哪些代码值得测试

很多同学做毕设时完全不写测试，能跑通就万事大吉。但这里要说句实话：答辩时评委问"你这个项目做没做过测试"，如果你回答"我都是手动测的"，其实也可以，但在系统设计一节加入几个真正有价值的单元测试，展示效果会完全不同。

毕设项目中值得写测试的代码集中在三类：一是订单状态流转测试，验证待支付、已支付、已取消、已入住、已退房这些状态迁移是否符合预期；二是价格计算测试，验证不同入住天数和房型价格组合下的金额是否正确；三是权限测试，验证未登录用户访问受保护接口是否返回401，普通用户访问管理接口是否返回403。

6.2 基于MockMvc的接口测试示例

Spring Boot提供的MockMvc可以直接模拟HTTP请求，不需要真的启动服务器，非常适合写Controller层的接口测试。

java复制@SpringBootTest
@AutoConfigureMockMvc
class OrderControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    void testCreateOrderWithoutToken() throws Exception {
        mockMvc.perform(post("/api/order/create")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{\"roomId\":1,\"checkInDate\":\"2025-06-01\",\"checkOutDate\":\"2025-06-03\"}"))
                .andExpect(status().isUnauthorized());
    }
}

测试的核心意图是验证"未登录不能下单"这一安全约束，而不是把测试写得多复杂。如果你能给出5到8个这样有针对性的测试用例，并且每个都跑通了，那这一部分在论文中的分量会比很多人写两页的"系统测试"更扎实。

6.3 单元测试的最佳实践建议

写单元测试时有一个原则：测试要快、要独立、要可重复。不要让单元测试依赖真实数据库，可以使用H2内存数据库，或者用@MockBeanMock掉Mapper层，让Service层的测试不依赖数据库环境。真正确认SQL和表结构正确性，可以放到集成测试阶段，连上开发库做一次完整的流程回归。

7. 打包部署与环境适配：从本地运行到Docker容器

7.1 项目打包：跳过测试、指定Profile

毕设项目最后提交的往往是一套能运行的源码和演示视频。最稳妥的交付方式是把前后端分别打包，后端用Maven打包成可执行的Jar包，前端用npm run build生成静态文件放到Nginx里。

Maven打包命令如下：

bash复制mvn clean package -DskipTests -Pprod

-DskipTests跳过单元测试，避免测试用例不过导致打包失败；-Pprod激活生产环境的Profile，让Jar包直接读取生产数据库配置。打包完成后，在target目录下会生成hotel-system-0.0.1-SNAPSHOT.jar。

7.2 JDK版本与Spring Boot版本的匹配问题

"springboot jdk1.8打包到docker desktop"这个搜索热度让我想多说几句。JDK 8 + Spring Boot 2.7.x的组合打包成镜像，整体是成熟稳定的，但有两个容易踩坑的地方。

第一个坑是Docker基础镜像的选择。JDK 8有多个镜像变体，建议使用eclipse-temurin:8-jdk，它比旧版的openjdk:8-jdk-alpine更可靠，因为Alpine版本在一些场景下会有字体、时区、glibc兼容问题。第二个坑是Docker容器时区，默认是UTC时间，数据库里写入的时间会比本地时间早8小时。处理办法是在Dockerfile里加一行设置时区的指令。

dockerfile复制FROM eclipse-temurin:8-jdk
WORKDIR /app
ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
COPY target/hotel-system-0.0.1-SNAPSHOT.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

7.3 Docker Compose编排：MySQL与后端服务一起启动

一个完整的项目除了应用服务，还需要数据库服务。推荐使用docker-compose.yml把MySQL和应用一起编排，这样在答辩演示环境或新的服务器上，只需要一条命令就能把整个系统拉起来。

yaml复制version: '3.8'
services:
  mysql:
    image: mysql:8.0
    container_name: hotel-mysql
    environment:
      MYSQL_ROOT_PASSWORD: root123456
      MYSQL_DATABASE: hotel_db
    ports:
      - "3306:3306"
    volumes:
      - ./sql:/docker-entrypoint-initdb.d
    command: --default-authentication-plugin=mysql_native_password

  app:
    build: .
    container_name: hotel-app
    depends_on:
      - mysql
    ports:
      - "8080:8080"

./sql目录下放数据库初始化脚本，MySQL容器第一次启动时会自动执行，这样整个项目的部署就只剩docker-compose up -d这一条命令了。这个部署方案在毕设演示和答辩时非常加分，因为很多同学在答辩现场因为环境不一致跑不起来，而容器化部署方案彻底规避了这个问题。

7.4 线上部署的数据库账号与安全配置

生产环境部署时，千万不要用root账号连接数据库。正确做法是单独创建一个应用账号，授予其仅对hotel_db的增删改查权限。同时，application-prod.yml中的密码不要明文写在配置文件里，可以用环境变量占位符。

yaml复制spring:
  datasource:
    url: jdbc:mysql://mysql:3306/hotel_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

这个做法虽然简单，但能体现安全意识。毕设项目如果连密码都是硬编码在整个项目里的，答辩时评委一旦问到安全问题，会显得准备不足。

8. 答辩高频问题与源码讲解路径

8.1 Spring Boot自动装配原理：必问项

答辩或者面试时，"Spring Boot自动装配原理"几乎是必问题。要理解它，就要抓住@SpringBootApplication这个注解背后的三个核心注解：@SpringBootConfiguration标明当前类为配置类；@ComponentScan扫描当前包及其子包下的组件；@EnableAutoConfiguration是自动装配的总开关。

@EnableAutoConfiguration的底层是通过AutoConfigurationImportSelector类，在项目启动时扫描所有META-INF/spring.factories（Spring Boot 3.x版本是META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports）文件中的自动配置类，然后根据@ConditionalOnClass、@ConditionalOnMissingBean等条件注解判断哪些自动配置生效。

举例来说，当你引入spring-boot-starter-data-redis后，自动装配机制发现类路径下存在RedisTemplate类，就会自动创建RedisConnectionFactory和RedisTemplate的Bean，而你不需要做任何配置。讲清楚这套"约定优于配置"的机制，评委对你的印象会立刻提升一个档次。

8.2 如何向评委讲解项目：路径规划

在评委打开你的项目时，不要直接从头到尾讲代码，要先给出一条清晰的讲解路径：

第一步，讲清楚系统边界：系统分为用户端和管理端两个部分，用户端解决"在线预订"问题，管理端解决"酒店运营配置"问题；第二步，演示核心链路：注册/登录 -> 选择日期 -> 搜索房间 -> 提交订单 -> 模拟支付 -> 在订单列表看到订单状态变化，再到管理端把订单标记为已入住、已退房；第三步，展示设计亮点：找2到3个自己真正理解透彻的技术点展开，比如可订房间查询SQL中的日期重叠判断、订单状态机设计、JWT无状态鉴权，甚至是Docker Compose一键部署。

如果你能"边操作边讲解"，让评委看到订单状态从待支付变成已支付、再从已支付变成已入住，这比任何华丽的PPT都更有说服力。

8.3 源码阅读指引：拿到项目后如何快速上手

对于下载了这套"Spring Boot酒店便捷预定系统"源码的同学，我建议不要一开始就沉到代码细节里，按照下面的顺序去读源码会高效得多。

建议先用Navicat或者命令行工具把sql目录下的初始化脚本导入MySQL，确认数据库表结构和基础数据存在。然后找到项目的application-dev.yml，改成你本地的数据库账号密码，启动HotelApplication.java。第三步，用Swagger或者Postman调通/api/auth/login接口，拿到Token后就可以用Authorization请求头访问其他需要鉴权的接口了。最后根据"Controller -> Service -> Mapper"这条调用链去读代码，不要逆着读。

9. 开发过程中的常见问题与解决记录

9.1 端口被占用的处理

Spring Boot默认端口是8080，开发过程中最容易遇到Port 8080 was already in use的情况。这通常是之前运行的实例没有完全停掉，或者是其他程序占用了8080端口。

Windows下可以使用netstat -ano | findstr 8080找到占用端口的进程PID，再用taskkill /F /PID <pid>强制结束进程。另一种方案是在application.yml中显式修改server.port，比如设置成server.port: 8081，这个方法也适合本地多个项目同时跑的场景。

9.2 MyBatis-Plus分页插件与数据类型映射

数据库的时间字段在实体类中用LocalDateTime类型对应，前端返回时默认会序列化成数组格式，如[2025, 5, 1, 12, 30, 0]，而不是字符串"2025-05-01 12:30:00"。为了避免这个接口对接问题，需要在实体的时间字段上添加@JsonFormat注解指定格式，或者统一配置Jackson的日期格式。

java复制@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")
private LocalDateTime createTime;

9.3 跨域问题

前后端分离开发模式下，前端运行在http://localhost:9528，后端运行在http://localhost:8080，两个端口之间访问必然产生跨域问题。后端解决跨域的标准做法是配置CORS，可以写一个WebMvcConfigurer，也可以在Spring Security配置中允许跨域并添加CORS配置源。

java复制@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);
    }
}

生产环境要注意，这里的allowedOriginPatterns("*")只是为了本地开发方便，上线时应该限定为前端实际访问的域名地址。

9.4 热门搜索中的常见配置项

再看一遍近期关于"springboot配置""springboot 如何上传下载大文件""springboot整合activemq"这些搜索热词，它们指向的问题在酒店预定系统里也有对应的落地场景。前端上传房间图片时，spring.servlet.multipart.max-file-size默认是1MB，如果图片稍大就会报错，可以在application.yml中调大配置；消息队列如果不想引入ActiveMQ这么重的中间件，Spring Boot自带的ApplicationEvent事件机制也能够实现"订单创建后发通知"这类简单的解耦需求，对毕设完全够用。

10. 从毕设到简历项目：这套系统还能怎么扩展

这个酒店预定系统的价值不只在于做完交差。如果你能在此基础上再往前走一步，把系统中的某一两个模块做深做透，这个项目完全可以直接作为求职简历上的核心项目经历。

比较推荐的扩展方向有三个。一是分布式会话与缓存方向，把房间信息和用户Token缓存到Redis，减少数据库压力，简历上写"基于Redis缓存热点数据，接口响应时间下降40%"，这是招聘方很关注的技能点；二是消息队列异步方向，引入RabbitMQ或ActiveMQ，订单创建成功后通过消息队列异步发送通知，让系统架构从单一同步调用演进到异步解耦；三是部署架构升级方向，将单体应用拆分为Nginx + 前端静态文件 + 后端服务 + MySQL的部署结构，甚至把Redis加进来，展示你具备基本的部署运维能力。

记住，一个能讲清楚、能扛住追问的项目，胜过三个浮于表面的项目。把酒店预定系统里面最核心的订单状态机和可订房间查询算法吃得透透的，面试官问任何一个细节，你都能回答出设计原因和优化空间，这才能真正成为你的项目积累。

这套系统的后续维护建议是：代码里的注释要舍得写，尤其写明每个接口的入参、出参和业务约束；复杂SQL的旁边写清楚业务逻辑和设计思路；固定版本的依赖统一锁定，禁止随意升级。过一段时间你再回头看，会感谢当时用心标注的自己。