企业官网建设流程全解析

1. 为什么 SpringBoot 成为酒店管理系统毕业设计的首选

1.1 一个真实的选题心路——从“不知道做什么”到“选定酒店系统”

每年到了毕业设计选题季，计算机专业的同学基本都逃不开这几个方向：管理系统、电商系统、社交平台、内容博客。我辅导过的学生里，做酒店管理系统的比例一直不低，原因其实很现实——酒店管理系统的业务边界非常清晰，功能模块的划分几乎是教科书级别的：房间管理、客户管理、预订管理、入住退房、订单结算、统计报表。这种清晰的模块划分对毕业设计来说天生友好，需求分析、数据库设计、功能实现、论文撰写每一步都有明确的抓手，不会做着做着发现自己在“造轮子”的路上越走越远。

另一个关键点是技术栈的匹配度。SpringBoot + MyBatis/MyBatis-Plus + Vue 或者 SpringBoot + Thymeleaf，这两套组合是当前绝大多数高校毕业设计的主流配置。酒店管理系统正好能把 SpringBoot 的核心能力完整地展示一遍：Spring MVC 的请求处理流程、Spring Data JPA/MyBatis 的持久层操作、事务管理、拦截器/过滤器做登录验证、AOP 做日志记录、定时任务做房间状态自动更新。这些正好是答辩时老师最常追问的技术点。

如果你正在纠结选题，又希望这套系统能兼顾“实现难度适中”和“技术含金量达标”，酒店管理系统确实是个不会翻车的选择。但前提是——你不能只是去网上下一份源码改个名就交差。下面我先从选型说起，把一套完整的项目搭建思路拆给你看。

1.2 版本选型为什么会让你翻车——SpringBoot 版本太高怎么办

网上关于 SpringBoot 的项目源码多如牛毛，但你会发现一个高频出现在热词里的问题：“springboot版本太高怎么办”。这不是个别现象，而是大量应届生在导入开源项目时遇到的真实困境。

举例来说，你下载了一份基于 SpringBoot 2.3.7 的酒店管理系统源码，本地却装了 JDK 17，新建项目时惯性选了 SpringBoot 3.2.x。结果就是：

• javax.servlet 包全部变成 jakarta.servlet，代码里所有 import 直接标红
• Springfox（Swagger2）与 SpringBoot 3.x 不兼容，启动直接报错
• 部分配置项（比如 server.connection-timeout）在新版本里改了位置

我的建议非常直接：毕业设计没必要追求最新版本。SpringBoot 2.7.x 是 2.x 系列的最终版本，稳定性好、教程资源最多、绝大多数第三方 starter 都完美兼容，JDK 8 即可运行，非常适合作为毕设的基础版本。SpringBoot 3.x 适合已经工作的开发者去适配新项目，对毕设来说只是徒增排查兼容性的工作量。

如果你手里的源码是旧版本，而你的环境比较新，优先做“降级处理”而不是“升级迁移”：把本地 JDK 装成 1.8，IDE 里 Project Structure 的 SDK 改成 1.8，Maven 的 compiler 版本也改成 1.8。先跑通，再谈优化。毕业设计的核心是完整地展示业务逻辑和工程能力，而不是展示“我能搞定 SpringBoot 3 的兼容迁移”。

1.3 数据库选型与 ORM 框架的选择逻辑

酒店管理系统的数据量级在毕设场景下不会太大，MySQL 8.x 是绝对的主流选择，原因无他——教程多、问题解答多、Navicat 等可视化工具体验好。部分学校要求使用 SQL Server 或者 Oracle，也能无缝切换，但 SQL 方言上需要留意分页写法差异。

ORM 框架上，MyBatis-Plus 是比原生 MyBatis 更适合毕设的选择。为什么？因为它的 CRUD 接口是内置的，你不需要为每张表手写 BaseMapper 的增删改查 SQL，而是把精力集中在那些真正有业务价值的 SQL 上——比如多表联查订单明细、统计月度入住率、查询某个日期段内房间的空闲状态。这些才是答辩时能拿出来讲的东西。

我见过不少学生用 JPA 做酒店管理系统，JPA 在简单 CRUD 上确实更“省”，但复杂的动态条件查询（比如“查询 2024 年 6 月到 8 月之间入住过三次以上的会员客户”）用 JPA 写起来会比较绕，MyBatis-Plus 的 QueryWrapper 则天然适合这种拼装逻辑。这个选择看似不起眼，实际上会直接影响你后期开发的心情和效率。

2. 酒店管理系统的核心数据模型拆解

2.1 数据表设计是整个项目的承重墙

很多同学拿到源码之后第一件事是看 controller、service，我反而建议第一件事是打开数据库脚本，把表结构捋一遍。数据模型决定了业务的上限，表设计不合理，后面写多少代码都是在打补丁。

一个标准的酒店管理系统，核心表至少有这些：

这里有一个常见的设计分歧：预订和订单要不要拆成两张表？我倾向拆。因为预订只是一个“意向占房”，可能取消；订单是“已经发生的事实”，涉及金额结算。合在一起的话，状态流转会非常混乱——一个被取消的预订却不能删除，因为它和订单共用了一条记录，删除会导致金额数据丢失。

2.2 状态字段的设计：不要用魔法值写死在代码里

一个细节特别能体现工程素养：房间状态、订单状态这类字段，务必定义成枚举或者常量类，不要直接散落 0、1、2 这种魔法值。你在 controller 里写if (room.getStatus() == 1)的时候觉得挺顺手，到后面写统计报表、写定时任务、写条件查询时，你会到处找“1 到底代表什么”。

以房间状态为例，我通常会定义一个枚举：

public enum RoomStatus { AVAILABLE(0, "空闲"), BOOKED(1, "已预订"), CHECKED_IN(2, "入住中"), CLEANING(3, "打扫中"), MAINTENANCE(4, "维修中"); private final int code; private final String desc; RoomStatus(int code, String desc) { this.code = code; this.desc = desc; } public int getCode() { return code; } public String getDesc() { return desc; } }

这样在业务代码里就是RoomStatus.CHECKED_IN.getCode()，语义一目了然。对于前后端交互，返回给前端的 status 建议同时附上可读的中文描述，不要只扔一个 int 让人自己去猜。

2.3 金额计算的精度问题：BigDecimal 是必选项

客房价格、订单总金额、押金、消费记录，这些字段如果你用了 double 或者 float，那么结算时大概率会出现0.1 + 0.2 = 0.30000000000000004的经典问题。虽然酒店管理系统在毕设层面可能不会有人拿几十万条数据去压测，但答辩老师一旦看到你的金额字段是 double，这可是一个非常容易被追问到的硬伤。

数据库层面用 DECIMAL(10, 2)，Java 实体类用 BigDecimal，MyBatis 的 typeHandler 会自动做转换。涉及乘法除法时，注意divide方法必须指定精度和舍入模式，比如price.divide(new BigDecimal("3"), 2, RoundingMode.HALF_UP)，否则遇到除不尽的情况会直接抛 ArithmeticException。

3. 从零搭建 SpringBoot 酒店管理系统：关键功能实现思路

3.1 搭建项目骨架：从 idea 创建 SpringBoot 项目开始

热词里另一个高频词是“idea创建springboot项目”，说明很多人在第一步就被卡住了。这里分享一套稳定不踩坑的操作路径：

1. 打开 IntelliJ IDEA，选择 Spring Initializr，Server URL 保持默认即可。
2. Group 填com.example，Artifact 填hotel-management，Package name 自动生成。
3. 关键点：Type 务必选择 Maven，不要选 Gradle。虽然 Gradle 也很好，但网上绝大多数的毕设源码都是 Maven 工程，统一用 Maven 能避免很多导入期的依赖问题。
4. Java Version 选 8 或 11，取决于你本地 JDK。Packaging 选 Jar。
5. 依赖勾选：Spring Web、MyBatis Framework（或 MyBatis-Plus 的依赖手动引入）、MySQL Driver、Lombok、Spring Boot DevTools（可选，开发时热部署用）。
6. 生成完毕之后，pom.xml里手动追加 MyBatis-Plus 的 starter 依赖（因为 Initializr 不自带）。

启动类写好之后，先跑一个空项目确认端口 8080 能正常起来，再开始写业务代码。这一步可以帮你提前暴露环境问题，而不是等代码写了一堆再来排查。

3.2 登录认证与拦截器：永远不要在 controller 里重复写权限判断

酒店管理系统有角色区分——管理员、前台、客房保洁、财务，不同角色能访问的接口不一样。如果每个 controller 都写“判断当前用户是不是管理员”，代码会非常冗余，而且容易漏。

正确的做法是自定义一个拦截器，统一做登录校验和权限校验：

@Component public class AuthInterceptor implements HandlerInterceptor { @Autowired private IUserService userService; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 String uri = request.getRequestURI(); if (uri.contains("/login") || uri.contains("/register")) { return true; } // 从 session 或 token 中获取用户信息 HttpSession session = request.getSession(); User user = (User) session.getAttribute("user"); if (user == null) { response.setContentType("application/json;charset=UTF-8"); response.getWriter().write(JSON.toJSONString(Result.fail("未登录"))); return false; } // 权限校验：根据注解或路径规则判断 if (requiresAdmin(handler) && !RoleEnum.ADMIN.getCode().equals(user.getRole())) { response.getWriter().write(JSON.toJSONString(Result.fail("无权限"))); return false; } return true; } }

然后在 WebMvcConfigurer 里注册拦截器，指定拦截路径为/**，排除静态资源和登录接口。这样你的业务接口里就不需要再关心“这个用户是谁”，只需要从UserContext（ThreadLocal 封装的用户信息）里取当前登录人即可。

如果你的毕设采用了前后端分离（SpringBoot 只做 API），那么 JWT 是更合适的方案。用户在登录接口拿到 token，后续每次请求在 Header 里带上Authorization: Bearer <token>，后端用拦截器解析校验。注意 token 密钥不要硬编码在代码里，放到application.yml中，答辩时还能讲一下“配置外部化”这个点。

3.3 预订与入住：业务流转是答辩的核心谈资

酒店管理系统的业务主链路是：客户到店/电话预订 -> 前台确认预订 -> 到店办理入住 -> 在店消费 -> 退房结算 -> 房间转为打扫 -> 保洁完成后恢复可售。这条链路必须完整闭环，否则系统只是“一个带界面的 Excel”。

预订模块实现的关键逻辑是防重复预订。同一个房间在同一时间段内只能被有效预订一次，这个校验不能只靠前端，后端必须做兜底：

public boolean checkRoomAvailable(Long roomId, LocalDate checkInDate, LocalDate checkOutDate) { LambdaQueryWrapper<Reservation> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Reservation::getRoomId, roomId); wrapper.in(Reservation::getStatus, ReservationStatus.BOOKED.getCode(), ReservationStatus.CHECKED_IN.getCode()); // 时间段重叠判断 wrapper.and(w -> w.lt(Reservation::getCheckInDate, checkOutDate) .gt(Reservation::getCheckOutDate, checkInDate)); return baseMapper.selectCount(wrapper) == 0; }

这个重叠区间判断的 SQL 是经典的“时间区间重叠”模型：新预订的入住时间小于已有订单的离店时间，且新预订的离店时间大于已有订单的入住时间，两者同时满足即冲突。能把这个逻辑讲清楚，在答辩中的含金量远高于“我用了 MyBatis-Plus 的 crud 接口”。

入住之后，房间状态从“已预订”变成“入住中”，同时生成订单记录。退房时根据订单里的入住日期和实际退房日期计算住宿天数，再叠加消费记录表里的金额，得出最终结算金额。注意一个边界情况：提前退房或者续住，需要允许修改预计离店日期，重算金额时日志要记录原来的金额和修改原因，方便对账。

3.4 自定义 Banner、动态条件查询与分页——细节决定项目质感

热词里有一个很有意思的：“springboot banner生成器”。很多毕设项目启动时那一行默认的 Spring Boot logo，其实可以通过banner.txt换掉。用在线 banner 生成器（比如 patorjk.com 的 text to ASCII art）生成一个“Hotel Management System”的 ASCII 艺术字，放到src/main/resources/banner.txt下。这个小细节不值钱，但答辩演示时项目启动的一瞬间，观感会好很多。这种细节体现的是你对工程的认真程度。

再说分页。酒店管理系统的核心列表页——房间列表、订单列表、客户列表——都需要分页。MyBatis-Plus 的分页插件配置非常简单：

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

然后 service 里直接用Page<User> page = userMapper.selectPage(new Page<>(current, size), queryWrapper)。前端只需要传入 pageNum 和 pageSize，返回结果里带上 total、pages，前端分页组件轻松对接。

动态条件查询则是列表页的刚需——比如订单列表按“客户姓名”“入住日期范围”“订单状态”过滤。MyBatis-Plus 的 QueryWrapper 写起来非常顺手：

LambdaQueryWrapper<Order> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(query.getName()), Order::getCustomerName, query.getName()); wrapper.ge(query.getStartDate() != null, Order::getCheckInDate, query.getStartDate()); wrapper.le(query.getEndDate() != null, Order::getCheckOutDate, query.getEndDate()); wrapper.eq(query.getStatus() != null, Order::getStatus, query.getStatus());

比拼接 XML SQL 干净得多，又能避免 SQL 注入风险。StringUtils.isNotBlank 这种条件判断能保证“用户没填这个条件就不参与过滤”，这是动态查询的基本功。

4. 踩坑实录：我在酒店管理系统开发中遇到的五个问题

4.1 日期时间类型的选择：LocalDateTime 还是 Date

这个问题在很多老教程里是模糊的，导致大量毕设代码里 Date、Timestamp、LocalDateTime 混用。我的建议很明确：统一使用 LocalDateTime/LocalDate，理由有三个：

• LocalDateTime 有更清晰的时间比较 API，比如 isAfter、isBefore
• 配合 Jackson 序列化使用时，可以全局配置日期格式，避免返回给前端的是时间戳字符串
• MyBatis-Plus 对 LocalDateTime 有内置支持，配合 MySQL 的 datetime 类型完全无痛

在application.yml里做全局日期格式化配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这样后端返回给前端的 LocalDateTime 就不会是一长串时间戳 s 了。这个坑不大，但很多人在联调时才发现前后端日期对不上，前端表格里显示一行 1700000000000，很影响观感。

4.2 事务失效：同一个类内部调用 this.xxx() 的问题

退房结算这个操作，涉及多个表的修改：更新房间状态、修改订单金额、插入消费记录。这一组操作必须在一个事务里，否则中间任何一步失败都会导致数据不一致。

常见错误是：在 Service 类里写了一个@Transactional的方法 A，然后同类的无事务方法 B 调用了 A。由于 Spring 事务默认基于 AOP 代理，同类内部调用不会经过代理对象，事务直接失效。

解决办法有两个：一是把需要事务的方法拆到另一个 Service 类中，由外部调用；二是在类内部注入自身代理：

@Autowired @Lazy private OrderService self; public void checkOut(CheckOutDTO dto) { self.doCheckOut(dto); } @Transactional(rollbackFor = Exception.class) public void doCheckOut(CheckOutDTO dto) { // 1. 更新房间状态 // 2. 计算订单金额 // 3. 插入消费记录 // 4. 生成结算流水 }

另外注意@Transactional默认只回滚 RuntimeException 和 Error，如果你在业务代码中手动 catch 了异常并吞掉，事务一样不会回滚。所以方法内部不要随便 catch Exception 后不抛出，至少也要抛出运行时异常或者用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 做手动回滚。

4.3 多表关联查询：不要一味追求“一个接口全查出来”

初学者最容易犯的毛病：一个订单列表接口，把客户、房间、订单、消费记录全部 join 出来，返回给前端一个巨大的 JSON。页面加载慢不说，后端代码里全是一大坨 VO 类。

更好的做法是按需查询、接口拆分：

• 订单列表接口只返回订单基础信息 + 客户姓名 + 房间号，也就是列表页表格需要的那几列
• 点击某条订单进入详情时，再调用订单详情接口，查询消费记录、押金记录等明细

这样每个接口的职责非常单一，前端也更容易维护。同时要注意 join 查询时字段别重名，比如客户表有phone，用户表（操作员）也有phone，在 SQL 里用别名区分：

SELECT c.name AS customer_name, c.phone AS customer_phone, u.name AS operator_name FROM t_order o LEFT JOIN t_customer c ON o.customer_id = c.id LEFT JOIN t_user u ON o.operator_id = u.id WHERE o.id = #{id}

4.4 密码加密存储：MD5 已经不适合直接裸露存储

毕设里最常见的密码处理方式是 MD5 加密，这当然比明文存储好得多，但从 2024 年的标准来看，仍然不够。至少使用加盐的哈希算法，Spring Security 自带的 BCryptPasswordEncoder 是更好的选择：

@Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } // 注册时 String encodedPwd = passwordEncoder.encode(rawPassword); // 登录时 boolean matches = passwordEncoder.matches(rawPassword, user.getPassword());

如果你不希望为了一个密码功能引入完整的 Spring Security，也可以只用它的 crypto 模块依赖，或者使用 Hutool 工具类提供的 BCrypt 支持。答辩时老师看见 BCrypt 而不是简单 MD5，通常会认为你对安全问题有基本认知。

4.5 静态资源映射：前端上传的图片为什么 404

酒店管理系统里常见的一个功能是上传房间照片。上传成功之后图片保存到了本地的/upload目录，但前端访问http://localhost:8080/upload/room123.jpg时返回 404。原因很简单：SpringBoot 默认只把classpath:/static/作为静态资源目录，你上传到了本地磁盘路径，并没有映射到 URL 上。

解决方案是在配置类中注册资源映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 将 /upload/** 映射到本地磁盘目录 registry.addResourceHandler("/upload/**") .addResourceLocations("file:D:/hotel/upload/"); } }

图片上传路径也建议配置到application.yml里，不要硬编码。对于毕设来说，使用本地磁盘存储图片已经足够，不必上云存 OSS。

5. 论文撰写与答辩准备：让源码价值最大化

5.1 论文结构：不要抄模板，要让逻辑闭环

很多学校的毕设论文有固定模板，但内容上你需要做到逻辑自洽：选题背景 -> 需求分析 -> 系统设计 -> 数据库设计 -> 功能实现 -> 系统测试 -> 总结。这条线必须对应到你的源码真实实现了什么，而不是“我参考了某系统然后做了一个功能更全的”。

需求分析阶段，重点写清楚系统的角色划分和用例图。比如酒店管理系统分为管理员（房间管理、价格设置、数据统计）、前台（预订、入住、退房、结账）、保洁（查看打扫任务、标记完成）、财务（对账报表、流水查询）。每个角色的用例要能在源码中找到对应的功能模块，答辩时老师如果翻开你的系统发现某个用例根本找不到入口，那会很被动。

系统设计部分，建议画清楚三层架构的包结构图：controller、service、mapper、entity、vo、dto、config、common。这看似是无聊的目录结构说明，但图一画出来，系统架构就非常直观。数据库设计部分用 E-R 图和表结构说明即可。

5.2 答辩高频问题：提前准备好这些答案

答辩时间通常只有 10-15 分钟，老师问的问题其实是有较高重复度的。针对酒店管理系统，我总结几个高频考题：

1. “你的系统怎么防止同一房间被重复预订？”答：后端在保存预订记录前执行时间重叠校验，查询条件是对应房间在相同时间范围内是否存在状态为“已预订”或“入住中”的记录。同时数据库层面可以给 room_id 和 check_in_date 建联合唯一索引作为兜底。

2. “你的金额是怎么计算和存储的？”答：金额字段统一使用 DECIMAL(10,2) 存储，Java 层用 BigDecimal 参与计算，避免浮点精度丢失。住宿费用 = 每晚房价 × 入住天数，入住天数按“退房日期 - 入住日期”取天数差，提前退房按实际天数结算。

3. “如果客户在退房时发现房间有物品损坏，你的系统怎么处理？”答：退房结算模块增加了“赔偿费用”明细项，前台录入赔偿金额后会自动累加到结算总额中，同时生成一条消费记录，关联到订单号和操作员 ID，保证账目可追溯。这个点如果你没做，答辩前也值得补上，它很能体现业务思考的完整性。

4. “你的系统并发能力怎么样？”答：毕设阶段可以用“在事务 + 数据库索引 + 乐观锁/悲观锁层面保证数据一致性”的思路回答。比如更新房间状态时使用乐观锁（版本号字段），即使两个前台同时操作同一间房，也只有一个请求能成功。这一句能展示你对并发的基本理解。

5.3 给源码项目“内增高”：加什么功能既不难又能加分

如果时间充裕，我建议在基础功能之上加一两个“差异化模块”，以下三个方向性价比最高：

• 数据可视化大屏：用 ECharts 实现入住率趋势图、房型偏好饼图、月度营收柱状图。ECharts 是纯前端组件，后端只需要提供统计接口，实现成本低，但演示效果非常直观。
• 定时任务自动处理未支付订单：用 Spring 的@Scheduled注解做定时任务，每天凌晨清理超过 24 小时未支付且无押金的预订订单，房间自动释放。这个功能同时涉及定时任务和状态流转，是很不错的加分项。
• 操作日志切面：定义一个自定义注解@LogAnnotation(module = "订单模块", action = "退房结算")，用 AOP 切面统一记录操作日志。这一块展示了 Spring AOP 的应用能力，是纯代码层面的亮点。

以上三个功能各有侧重：ECharts 展示前端与可视化能力，定时任务展示并发与异步思维，AOP 展示架构设计能力。选一个做深做透，比多两个半成品模块更有说服力。

6. 源码阅读与二次开发：怎么把别人的代码真正变成自己的东西

6.1 导入源码的正确姿势

拿到一份源码之后，千万不用急着双击打开。先按这个顺序做“环境体检”：

1. 读 README 或者项目文档，确认 JDK 版本、MySQL 版本、Maven 版本、是否需要 Redis。
2. 检查application.yml中的数据库连接、端口配置、文件上传路径，逐项改成你本机的配置。
3. 在 Navicat 中执行数据库脚本，把表结构和初始数据都导进去。注意脚本执行顺序，先建库再建表，不然外键关联会报错。
4. 使用 IDEA 的Open而不是New打开项目，等待 Maven 自动下载依赖。如果下载缓慢，在settings.xml中配置阿里云镜像：

   <mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/central</url> </mirror>

5. 启动项目，确认控制台没有红色报错。前后端分离的项目，还要先启动前端工程（npm install -> npm run dev）。

跑通之后的第二步读代码，我建议顺序是：pom.xml（看用到了什么技术） ->application.yml（看配置） -> 启动类 -> 一个从前端调用到 controller 再到 service 再到 mapper 的完整链路。把这个链路弄清楚，你对整个项目的理解就有了三条主线：请求如何进来、数据如何流转、权限如何控制。

6.2 二次开发：加一个“会员积分”模块的实战演练

以酒店管理系统最常见的二次开发需求——会员积分模块为例，演示怎么在已有架构上叠加功能：

1. 数据库加表：t_member_points（id, customer_id, total_points, used_points, update_time），以及积分明细表t_points_record（id, customer_id, order_id, points, type, create_time）。type 区分“消费获得”“兑换扣减”“过期失效”。
2. 定义实体和 Mapper：参照现有的 Customer 实体类风格写 MemberPoints、PointsRecord，Mapper 继承 BaseMapper。
3. Service 层：在结账退房成功后添加一个方法，按“消费金额每满 100 元积 1 分”的规则计算积分，开启事务写入积分与明细表。
4. Controller 层：新增积分查询接口，供前台查询客户当前积分；新增积分兑换接口，兑换时先判断积分是否充足，再扣除积分并记录明细。
5. 前端页面：在客户详情页添加“积分记录”标签页，调积分明细接口，展示列表。

这个模块的技术难点在“积分扣减是资金类操作，必须保证幂等”——兑换请求如果网络超时重试，不能重复扣积分。解决方案是前台生成唯一请求号（比如 UUID），后端加一个防重表，遇到相同的请求号直接返回上次处理结果。把这一点在论文里写出来，档次会完全不同。

6.3 代码优化清单：这些细节答辩老师一眼就能看出来

最后送你一份自查清单，挑选源码项目时或者自己写代码时，逐条过一遍：

• [ ] Controller 层是否只负责参数接收和结果返回？如果 controller 里超过 10 行业务逻辑，该考虑提到了 service。
• [ ] Service 层接口与实现是否分开？虽然毕设不强制，但接口加实现是更规范的做法。
• [ ] 实体类是否用了 Lombok？@Data注解可以大幅减少 getter/setter 样板代码。
• [ ] 是否定义了统一返回体？比如 Result 类，包含 code、msg、data 三个字段，配合@RestControllerAdvice做全局异常处理。
• [ ] 数据库查询是否避免select *？用select 字段列表或者 MyBatis-Plus 的select(实体::get字段)只查需要的列。
• [ ] 配置文件中是否有敏感信息硬编码？数据库密码、JWT 密钥至少放到 application.yml 的变量引用中，项目源码开源在 GitHub 时要格外注意。

这一路写下来，说的都是我自己带学生做毕设时反复遇到的真实问题。酒店管理系统这个选题之所以经典，不仅是因为业务清晰，更因为它能把你对 SpringBoot 工程化的理解完整地呈现出来。从选型到上线，每一步都有讲究，把这些细节扎实做好的过程，就是你把课程知识真正转化为工程能力的过程。无论你是打算下载源码二次开发，还是从零手写一版，最忌讳的是“拿到代码就急着跑”——先读数据结构，再理业务流程，最后才是动代码。把这几步走完，这套系统的每一行代码都会长在你自己的脑子里。