做过酒店管理系统毕业设计的同学都知道，这类题目看起来简单，真正动手才会发现坑很多：房间状态怎么维护？预订时怎么避免同一房间被重复下单？房费按什么规则计算？各种边界情况能把人绕晕。标题里带着 Spring Boot、Java 毕业设计、Vue 这些关键词，本身的定位已经比较清晰——做一个前后端分离的酒店管理系统。但经常又看到 PyCharm、Django 这些词混在搜索记录里，说明很多同学习惯把搜过的技术栈关键词一股脑堆在标题里，反而容易让指导老师误以为你选型思路不清晰。这篇文章我会把这个项目从技术选型、数据库设计、后端接口、前端页面到答辩验收的完整链路拆开讲，既有能直接落地的代码片段，也有我在帮别人改这类项目时积累的调试经验和避坑清单。适合正在选毕业设计题目、或者已经选了类似系统但还没理清架构的同学参考。

1. 标题关键词背后的真实技术诉求拆解

1.1 “Spring Boot + Java 毕业设计”到底要求什么能力

毕业设计选题最怕的就是“看起来简单，做起来没深度”。酒店管理系统属于典型的管理信息系统（MIS），它考察的核心能力有三块：一是能不能把业务规则转换成数据库表和接口逻辑，二是能不能把前端页面和数据交互做完整，三是能不能处理并发和异常这类“非教科书问题”。Spring Boot 在这里的作用是快速搭建后端骨架，把配置简化到最低限度，让开发者把精力集中在业务本身。我的建议是不要一上来就追求微服务、分布式这些花哨概念，老老实实把单体的 CRUD 做扎实，再在一两个点上体现思考深度，比如预订防冲突、房态自动流转、账单计算，这些已经足够支撑一篇合格的毕业论文。

1.2 为什么 Vue 会成为这类项目的标配前端

Vue 之所以在毕业设计里出现频率极高，是因为它对新手友好、生态成熟、中文资料多。酒店管理系统的前端核心是“房态图”——用格子表示房间，用颜色区分已入住、已预订、空闲、清洁中，这种界面用 Vue 的列表渲染和响应式数据来做非常顺手。同时，Vue 2 搭配 Element UI、Vue 3 搭配 Element Plus 能直接把表格、表单、弹窗、日期选择器这些组件拿来用，两三天就能拼出一个看起来不错的管理界面。相比传统的 JSP + 模板渲染，前后端分离的架构也更符合当前主流开发方式，答辩时更好讲。

1.3 PyCharm 和 Django 混入标题的原因分析

标题里出现 PyCharm、Django 其实是个典型的信息噪音。PyCharm 是 Python 的 IDE，Django 是 Python 的 Web 框架，它们和 Spring Boot + Java 并不兼容。出现这种情况通常是学生在搜索时看到多个相似项目，把不同方案的关键词直接拼在了一起。这里我想明确建议：不要混用技术栈。你选定了 Java + Spring Boot，后端就用 IntelliJ IDEA 开发，前端用 VS Code，数据库用 Navicat 或命令行，不要因为别人用了 PyCharm 就动摇。技术栈混用会导致代码写不下去、指导老师看不懂、答辩被追问时答不上来。如果确实对 Python 更熟悉，那就干脆用 Django + Vue 单独做一版，但不要把两套方案揉在一起。

1.4 酒店管理系统需要解决的核心业务模块

如果做一个功能完整的酒店管理系统，至少要覆盖以下模块：客房管理（房型、房价、房间状态）、预订管理（下单、取消、修改日期）、入住退房（登记、换房、续住、结算）、客户管理（散客信息、会员信息）、账单管理（押金、房费、杂费、退款）、数据统计（入住率、营业额）。以我的经验，多数同学把预订和房态这两块做好就已经占了大半工作量。房态是整个系统的中枢：客人预订成功后房间从“空闲”变成“已预订”；办理入住变成“已入住”；退房后变成“清洁中”，清洁完成才恢复“空闲”。这个状态机必须严格定义，否则会出现钱算不清、房排重的问题。

状态流：空闲 ──预订成功──> 已预订 ──办理入住──> 已入住 ──退房──> 清洁中 ──打扫完成──> 空闲

2. 技术选型与项目架构：为什么我推荐这套组合

2.1 Spring Boot 和 Django 的取舍到底怎么选

很多同学会在 Java 和 Python 之间犹豫，核心顾虑是“哪个更好做”。我直接说结论：如果标题已经写了 Spring Boot，就不要再想 Django。Spring Boot 的生态里，MyBatis-Plus 能极大简化数据库操作，Spring Security 或 JWT 方案做登录鉴权非常成熟，而且网上关于“Spring Boot + Vue 酒店管理系统”的参考项目一抓一大把，遇到问题容易搜到答案。Django 的优势是 admin 后台自带、ORM 写起来快，但它和 Vue 联调时跨域、序列化、权限控制的资料相对少一些，对基础薄弱的同学反而不友好。从评分角度看，Java 后端 + Vue 前端这种组合在毕业设计里非常主流，老师不会觉得选型有风险。

2.2 前后端分离的项目结构怎么规划

我习惯把项目分成三个目录：backend、frontend、database。backend 是 Spring Boot 工程，按 controller、service、mapper、entity 分层；frontend 是 Vue 工程，按 api、router、views、components 组织；database 放建表 SQL 和初始化数据脚本。这样的好处是清晰、可维护，论文里的系统设计图和目录结构能一一对应。下面是一个典型的目录规划：

hotel-management/ ├── backend/ # Spring Boot 后端 │ ├── src/main/java │ │ ├── controller/ # 接口层 │ │ ├── service/ # 业务层 │ │ ├── mapper/ # 数据访问层 │ │ ├── entity/ # 实体类 │ │ ├── common/ # 通用返回、异常、工具类 │ │ └── config/ # 跨域、拦截器、Swagger配置 │ └── src/main/resources/ │ ├── application.yml │ └── mapper/ # MyBatis XML 文件 ├── frontend/ # Vue 前端 │ ├── src/ │ │ ├── api/ # axios 请求封装 │ │ ├── router/ # 路由配置 │ │ ├── views/ # 页面 │ │ ├── components/ # 通用组件 │ │ └── utils/ # token、请求工具 │ └── vite.config.js └── database/ └── init.sql # 建表及初始化数据

2.3 数据库表设计是决定项目上限的关键

酒店管理系统的数据库通常包含以下核心表：管理员表（admin）、房型表（room_type）、房间表（room）、客户表（customer）、预订表（reservation）、入住表（checkin/checkout 合为 stay 表更简单）、账单表（bill）。我这里给出一版经过实践调整的表结构建议。

房间表 room 的核心字段是 id、room_number（房间号）、type_id（关联房型）、floor（楼层）、status（状态：0空闲 1已预订 2已入住 3清洁中）、price（实际售价，可以冗余房型价格以便处理促销价或临时调价）。预订表 reservation 的核心字段是 id、customer_id、room_id、check_in_date、check_out_date、total_amount、status（0待支付 1已确认 2已入住 3已取消 4已完成）、create_time。注意，预订时必须校验时间段是否重叠，这是整个项目最容易出 bug 的地方。

CREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_number VARCHAR(20) NOT NULL UNIQUE, type_id BIGINT NOT NULL, floor INT NOT NULL, status TINYINT DEFAULT 0 COMMENT '0空闲 1已预订 2已入住 3清洁中', price DECIMAL(10,2) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

2.4 开发环境选型中常被忽略的细节

环境这块我见过太多同学卡住：JDK 版本和 Spring Boot 版本不匹配导致启动失败，Maven 依赖下载慢到怀疑人生，Node 版本太新导致 node-sass 编译报错。这里给一套相对稳妥的组合：JDK 1.8 或 JDK 11，Spring Boot 2.7.x，MyBatis-Plus 3.5.x，MySQL 5.7 或 8.0，Vue 3 + Vite + Element Plus（或者 Vue 2 + Element UI，如果对 Vue 3 不熟悉就选 Vue 2，稳妥优先）。Maven 仓库建议配置阿里云镜像，Node 依赖安装时如果报错可以设置 registry 为国内镜像源。数据库连接工具用 Navicat 的免费版足够，也可以用 MySQL Workbench。

3. 后端实战：从骨架搭建到核心业务接口实现

3.1 用 Spring Initializr 初始化项目并配置依赖

创建后端项目时不要手动搭，直接访问 Spring Initializr（或者 IDEA 自带的 New Project 界面）生成基础工程。建议勾选的依赖有：Spring Web、MySQL Driver、MyBatis-Plus（如果初始界面没有就后续手动加）、Lombok、Spring Validation。生成后解压导入 IDEA。如果用的是 MyBatis-Plus，注意它有自己的 starter 坐标，不是原生 MyBatis 的依赖。

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

然后是 application.yml 的配置，核心是数据源、MyBatis-Plus 驼峰映射、日志级别。注意时区要设置成 Asia/Shanghai，否则数据库时间会差 8 小时。

spring: datasource: url: jdbc:mysql://localhost:3306/hotel_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

3.2 统一返回结果与全局异常：让前端少 30% 的判空代码

前后端分离项目里，接口返回格式不统一是非常影响开发效率的问题。我建议定义一个 Result 类，所有接口统一返回{ code: 200, message: "success", data: [...] }这种结构。前端封装 axios 时只需要拦截非 200 的 code 统一提示，不需要每个页面单独处理错误。

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

全局异常处理用@RestControllerAdvice做三个方向的兜底：参数校验异常（MethodArgumentNotValidException）、业务异常（自定义 BusinessException）、未知异常（Exception）。业务异常的用法是：预订冲突抛一个“该房间在所选日期内已被预订”，参数错误抛一个“入住日期不能晚于退房日期”，这样前端拿到错误信息可以直接展示，而不是看到一堆堆栈长文。

3.3 预订防冲突是系统核心难点，细节直接影响评分

预订接口是这个系统里最有含金量的地方，也是答辩时老师最爱追问的点。它的核心逻辑是：根据房间 ID 和入住/退房日期，查询数据库中是否存在「日期范围重叠」的预订记录或入住记录。重叠的判断条件写成 SQL 就是：

SELECT COUNT(*) FROM reservation WHERE room_id = #{roomId} AND status IN (1, 2) -- 已确认和已入住的预订才算占用 AND #{checkOutDate} > check_in_date AND check_out_date > #{checkInDate}

这段 SQL 的逻辑是：如果查询到的预订的入住日期早于本次入住请求的退房日期，并且该预订的退房日期晚于本次请求的入住日期，那么两个区间一定有交集。这个写法值得细品，它用一个条件同时处理了“预订开始日期早于查询开始日期”和“预订开始日期晚于查询开始日期”两种情况，不需要写一堆 if 判断。另外要注意，预订状态只有“已确认”或“已入住”才真正占用房间，“已取消”和“已完成”的记录要排除。

3.4 基于 JWT 的登录鉴权：单点登录在毕业设计里的简化实现

酒店管理系统的权限一般分两类：系统管理员（管理后台）和前台操作员（办理入住退房）。如果觉得设计角色太复杂，可以只做一个管理员角色，登录后返回 token，前端把 token 存在 localStorage 里，每次请求通过 axios 拦截器附带到 Authorization 头。后端的实现逻辑：

1. 用户登录时校验用户名密码，成功后用 JWT 生成 token。
2. JWT 的 payload 里放 userId 和 username，密钥写在配置文件中，有效期设 24 小时。
3. 写一个拦截器（HandlerInterceptor）拦截所有 /api/** 请求，校验 token 是否有效。
4. 如果是简单项目，可以不引入 Spring Security，直接用拦截器 + JWT 工具类就够了。不要担心“不够高级”，够用且你能讲清楚原理更重要。

public class JwtUtil { private static final String SECRET = "your-secret-key"; // 生成 token public static String generateToken(Long userId, String username) { return Jwts.builder() .claim("userId", userId) .claim("username", username) .setExpiration(new Date(System.currentTimeMillis() + 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } // 解析 token，无效会抛异常 public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

这里要特意提醒一个坑：使用 JJWT 库时，不同版本的 API 有变化，0.9.x 用的 signWith 带两个参数，新版本可能要求带 Key 对象。网上教程新旧混杂，复制代码时一定要先确认 import 的类是否能编译通过。如果你不想折腾 JWT，也可以直接用 Spring Session 或者简单的 token 表（存 UUID 和过期时间），效果类似，只是多一张表和多几次查询。

3.5 用 Swagger 生成接口文档，答辩演示会非常加分

很多同学忽略接口文档这件事，其实在答辩环节，现场打开 Swagger UI 展示接口列表和参数说明，会比打开 IDEA 翻代码直观得多。加上 Swagger 的配置也不复杂，引入 knife4j 或 springfox 依赖，加一个配置类，然后在 Controller 和实体类上补几个注解就行。最重要的是，Swagger 能让你在论文的“系统测试”章节里直接截图作为测试用例展示，省去手工整理表格的时间。接口设计时建议统一加版本前缀，比如/api/v1/**，这样后续如果改接口，前端和后端能同步调整。

4. 前端实战：Vue 页面如何与后端接口对表

4.1 Vite 脚手架与 axios 封装

前端用 Vite 创建 Vue 3 项目非常快，比起 Vue CLI 少了很多依赖安装时间。创建命令是npm create vite@latest frontend -- --template vue，然后进入目录安装依赖。这时候需要同时安装 vue-router、axios、element-plus。依赖装完之后，先别急着写页面，把 axios 封装好，这是前后端联调是否顺畅的关键。

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '../router' const request = axios.create({ baseURL: '/api', // 配合 Vite 代理，避免跨域 timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res.data } ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) }, error => { if (error.response?.status === 401) { ElMessage.error('登录已过期，请重新登录') localStorage.removeItem('token') router.push('/login') } else { ElMessage.error(error.message || '网络异常') } return Promise.reject(error) } ) export default request

注意这里有一个极其关键的细节：baseURL 设置成/api，同时配合 Vite 的 proxy 代理配置，把/api转发到后端localhost:8080。这样做的好处是第一，开发阶段不需要担心跨域问题，第二，部署到服务器时可以改用 Nginx 做反向代理，前端代码一行都不用改。这是我强烈推荐的联调方式，比在 axios 里写完整 URL 或者在 Spring Boot 里配 CorsFilter 都更接近真实生产环境。

4.2 核心页面一：房态图

房态页面是酒店管理系统的门面。我的实现思路是：从后端获取所有房间列表，按楼层分组，每个房间渲染成一个小卡片，颜色根据状态字段变化——绿色空闲、橙色已预订、红色已入住、灰色清洁中。点击空闲房间弹出“预订”或“直接入住”弹窗；点击已预订弹出“办理入住”或“取消预订”；点击已入住弹出“退房结算”或“换房”。这个逻辑其实就是一个大数组的响应式更新，但非常考验状态管理的条理性。我建议用一个 Map 结构存储房间号对应的房间对象，前端操作成功后重新调一次房间列表接口，避免本地状态和后端不一致。

<div v-for="room in floorRooms" :key="room.roomNumber" :class="['room-card', statusClass(room.status)]" @click="handleRoomClick(room)"> <span class="room-number">{{ room.roomNumber }}</span> <span class="room-type">{{ room.typeName }}</span> <span class="room-price">¥{{ room.price }}</span> </div>

4.3 核心页面二：预订与入住操作表单

预订表单的关键在于“日期范围选择”和“房间列表联动”。Element Plus 的日期选择器支持type="daterange"，用户选择入住和退房日期。之后的关键逻辑是：用户选择日期后，立刻调后端接口查询该时间段内有哪些空闲房间，用下拉列表展示。这个接口的 SQL 复用前面说的防冲突查询，把逻辑从“校验一个房是否可用”改造成“查全部可用房”。

@GetMapping("/available") public Result<List<RoomVO>> getAvailableRooms( @RequestParam String checkInDate, @RequestParam String checkOutDate) { // 1. 查所有房间 // 2. 查出这些房间在时间范围内被预订的 roomId 集合 // 3. 过滤掉被占用的，剩余即为可预订房间 List<Room> allRooms = roomMapper.selectList(null); List<Long> occupiedIds = reservationMapper.selectOccupiedRoomIds(checkInDate, checkOutDate); List<Room> available = allRooms.stream() .filter(room -> !occupiedIds.contains(room.getId())) .collect(Collectors.toList()); return Result.success(available); }

办理入住表单的核心字段是客户信息：姓名、身份证号、手机号、地址，外加押金金额。这里有经验的系统都会先查询该客户是否已有历史记录，如果是老客户，自动带出历史信息，减少前台录入工作量。退房结算则更复杂：要计算总房费（房价 × 天数）、杂费（如额外用品）、返还押金，最后生成账单记录。我的建议是把计算逻辑放在后端 service 里，前端只负责展示结果，不要让前端去算钱，否则来回校验非常痛苦。

4.4 路由守卫与按钮权限：前端权限控制的两个层次

很多同学做了登录功能，但前端默认所有人都能看到所有菜单，这会让老师直接扣分。简单项目可以用动态路由 + 按钮显隐两层次来控制：路由层面，未登录用户只能访问 /login，其他路由都要在 beforeEach 中检查 token 是否存在；菜单层面，根据用户角色字段（在登录响应里带上 role）决定显示哪些菜单。更细粒度的按钮权限可以用自定义指令控制，但毕业设计做到“未登录不能访问”“普通操作员看不到系统管理菜单”这两点就足够了。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { next() } else if (!token) { next('/login') } else { next() } })

4.5 联调阶段最容易出现的三个怪问题

前后端联调是毕业生最耗时的一环，我总结三个高频问题。第一是“后端能拿到数据，前端显示 undefined”——多半是实体类属性和前端字段命名对不上，比如后端是 roomNumber，前端写成 room_number；解决方案是统一用驼峰命名，后端实体加@JsonProperty或确保返回的 JSON 字段和前端一致。第二是“跨域报错”，如果没用代理而是直接请求后端地址，需要在后端加跨域配置，我的建议还是走代理。第三是“新增数据后列表不刷新”，这通常是因为新增和查询用了不同的接口状态，修改完没有重新拉列表，前端在成功后必须调用列表接口刷新数据，不要自以为增删改查会自动生效。

5. 实际开发过程中绕不开的坑与经验教训

5.1 环境类问题：版本匹配作为毕业设计的第一道坎

答辩的时候，老师最不想看的就是“系统启动失败”的演示现场。环境方面我总结了几条经验：Spring Boot 2.7 搭配 JDK 8 是最稳妥的组合，不要盲目用 Spring Boot 3.x，因为 3.x 要求 JDK 17，而且很多老教程里的写法在 3.x 下会报错。MyBatis-Plus 版本也别追新，3.5.x 就够。Node 环境如果装了 20+，某些老项目依赖可能编译失败，解决办法是用 nvm 切换到 16.x 或 18.x。还有一个很常见的坑：MySQL 8.0 和 5.7 的驱动配置不同，如果用 MySQL 8.0，driver-class-name 要用com.mysql.cj.jdbc.Driver，不能用旧版的com.mysql.jdbc.Driver。

5.2 数据库设计的三个后悔点

第一是日期类型。预订和入住相关的日期字段建议用 DATE 类型，不要用 DATETIME，否则后端和前端在时间解析上会频繁踩坑。第二是金额字段用 DECIMAL(10,2)，不要用 FLOAT 或 DOUBLE，浮点误差在退房结算时会发生“差一毛钱”的尴尬情况。第三是外键的使用要克制。毕业设计里可以在逻辑上关联两个表，但不一定非要建物理外键。物理外键会让删除数据非常痛苦，比如你想要测试“清除所有测试数据”，有外键约束就得按引用顺序删。我的做法是：关联字段建普通索引，业务层面的完整性由 service 层代码保证。

5.3 并发场景：如果不处理，答辩时容易被追问

酒店管理系统的并发问题虽然不及电商秒杀复杂，但老师很爱问：“如果两个操作员同时预订最后一个房间怎么办？”如果你什么都没做，就直接回答“数据库的乐观锁/悲观锁”。悲观锁实现简单——在查询房间时加SELECT ... FOR UPDATE，事务提交后释放锁。乐观锁则是在房间表加 version 字段，更新时比对版本号。我的建议是演示时把这一点讲清楚即可，不必真的做压力测试。哪怕你只写了乐观锁的 update SQL，也已经属于超纲亮点。

UPDATE room SET status = 2, version = version + 1 WHERE id = #{roomId} AND version = #{oldVersion}

5.4 论文与演示素材的整理技巧

论文写作时，不要只写“实现了一个酒店管理系统”这种苍白描述。建议准备五张图：系统总体架构图、数据库 E-R 图、核心功能流程图（预订流程）、系统功能模块图、部署结构图。这些图在后端代码骨架搭好之后就可以整理，不用等代码写完了再补。素材方面，Swagger 页面截图、房态图演示截图、退房账单截图都要中途就留好，否则临近答辩再回填截图，环境可能已经改得对不上了。在论文的“系统测试”章节，至少要给 8 到 10 个测试用例表格，覆盖各模块的正常流程和异常流程。

5.5 功能扩展方向：让项目从及格变成优秀

如果基础功能已经完成，还有余力，我建议加 1 到 2 个特色功能，这能明显拉开差距。高频的扩展方向有三个：一是房间状态统计，即首页展示当日入住率、营业额、各房型分布，用 ECharts 做图表，数据源就是 house 表的聚合查询；二是用户预约到期自动提醒，用 Spring 的定时任务扫描未来 24 小时内到达的预订记录并改变标记；三是会员积分或房价折扣策略，这个能体现你对业务规则的理解。要注意，扩展功能宁精勿多，一个能完整跑通的亮点远胜过三个半成品模块。

6. 完整跑通的验收清单：离交题前最后一周应该做什么

6.1 功能验收清单

到最后阶段，我建议按这份清单逐项自查，每一类都至少手测三遍：

• 管理员登录：错误密码提示、登录成功跳转、退出登录清除 token。
• 房间管理：新增房型、删除未入住房间、修改房间状态。
• 预订流程：选择可用房间、提交预订、重复时间段预订被拒绝、取消预订后房间恢复空闲。
• 入住流程：散客入住、押金收取、入住后房态变为已入住。
• 退房流程：计算房费与杂费、押金返还、房态变为清洁中。
• 客户管理：历史客户自动带出、新增客户、按手机号或身份证号搜索。
• 房态图联动：所有操作后房态图颜色刷新正常。

6.2 代码仓库与数据可靠交付

交题前把代码整理进 Git 仓库是加分项。重点不是代码写得多炫，而是提交记录清楚、每个提交对应一个小功能点。这样老师在评阅时看你确实是一步步推进的，而不是最后一天交了一坨代码。另外，数据库初始化脚本一定要写好，最好一条命令能完成建库、建表、填入管理员初始账号和部分演示数据。如果答辩时用的是一台新电脑，现场跑不通数据库环境是最尴尬的情况。我的建议是在论文里写清楚“部署步骤”：安装 JDK → 安装 MySQL → 执行 init.sql → 启动后端 → 启动前端 → 访问页面，每个步骤配一张截图。

6.3 演示脚本的设计：三分钟讲完核心逻辑

答辩演示时，一定不要从头到尾把每个功能都点一遍，时间不够，而且老师会很困。我建议的演示顺序是：登录 → 打开房态图 → 操作“某人打电话订房间” → 演示时间冲突被拒绝 → 办理入住 → 退房结算 → 展示营业额统计。整个过程要突出“你遇到了什么问题、怎么解决的”：时间冲突校验是你在开发时发现的真实问题，你用了区间重叠 SQL 来处理；退房计算要考虑押金抵扣，你封装了一个独立 service 方法。遇到老师追问不熟悉的问题，大方承认“这块我了解不深，目前只做了基础功能”都比编造答案强。

6.4 从课程设计到工程化的几个小改进

如果交完论文后你还打算把这个项目作为求职项目写在简历上，建议做三件事：第一，给后端加上 Redis 验证码缓存，哪怕只是模拟效果，也能体现缓存意识；第二，把日志从 System.out 改成 Slf4j ＋ Logback，按天滚动输出；第三，写一个 Dockerfile 让后端能跑在 Docker 容器里。这三件事每一件单看技术含量不高，但组合起来立刻会让项目显得更专业。我见过太多同学的项目功能完整，但代码一打开全是 System.out.println，口头上讲得再好也会被打折。

7. 我的一些实在建议

最后分享几条我在复盘这类项目时的心得。第一个心得是“不要想着抄最完整的代码”。网上的开源酒店管理系统非常多，但很多代码结构混乱、表设计不严谨，直接拿来改反而比从零写更痛苦。我更建议的做法是：参考两三份项目的表结构和接口设计，画出自己的数据库 E-R 图，然后按自己的理解按模块写代码。哪怕代码写得磕磕绊绊，答辩时你能说明白每一行在干什么，就已经赢了。

第二个心得是“测试数据一定要造得像样”。很多同学本地只放了三条房间数据，演示时房态图一片空白，视觉上就输了一半。我建议至少准备 30 个房间，覆盖 5 种房型、6 个楼层，再准备几组时间交叉的预订数据，这样演示时房态图五颜六色，统计页面的图表也有数据支撑，观感完全不同。

第三个心得是要保护好本地开发环境。毕业设计周期长，有时候一个月没动代码，再打开就启动失败了，多半是 MySQL 服务没启动、端口被占用、或者依赖包损坏。我会在项目根目录写一个 README 文件，记录启动命令、账号密码、常见问题排查方法。这个习惯很短视，但真能救急；同时，它本身也是工程素养的一部分。

这个项目做完后，你会发现“酒店管理系统”听起来虽然普通，但它把一个业务系统的完整链路都覆盖到了。如果还有队友或同学问你怎么选课设题目，我通常建议选这种中等规模、业务闭环清晰、前后端分离系统的方向，不要选太空泛的“XX管理系统”也不要选太偏算法的方向。系统的功能边界越清晰，你越容易把控进度，论文也越好写。祝所有正在和毕业设计搏斗的同学都能顺利通关。