企业官网建设流程全解析

本文还有配套的精品资源，点击获取

简介：基于SpringBoot开发的酒店业务系统，支持管理员、前台员工、普通客户三类角色独立使用。管理员可配置房型、维护房间信息、管理操作员账号；前台员工能实时办理入住登记（自动计算预估费用）、快速退房结账、查看预订状态、维护客户档案，并生成日/月业务统计报表；客户可通过网页浏览酒店信息、注册登录、查询实时房态、在线选房预订及管理个人订单。技术栈采用Java语言，整合Spring MVC、Spring Data JPA（或MyBatis）等主流框架，模块划分清晰，controller/service/dao/entity分层规范，Maven工程结构完整，包含pom.xml依赖配置、标准src目录、启动类和基础README说明，适合作为高校课程设计、毕业设计或中小型酒店初期信息化部署参考实现。

1. 项目概述：为什么这套酒店系统值得你花时间细读？

我带过六届计算机专业毕业设计，每年都有至少二十个学生在“酒店管理系统”和“图书管理系统”之间反复横跳。但说实话，绝大多数人交出来的版本，连前台员工退房时要不要自动释放房间状态都懒得判断——更别说把客户预订、前台入住、后台配置这三股绳真正拧成一股力了。而这套名为“酒店多角色协同管理系统”的源码，恰恰是我在本地一家连锁民宿做信息化顾问时，带着两个实习生从零搭起来的实战产物。它不是教科书里那种“用户登录→跳转首页→点击预订→弹出成功”的演示玩具，而是真正在凌晨两点帮前台小妹快速处理醉酒客人临时加床、在国庆节前夜批量导出37间房的预订冲突清单、让老板娘不用翻Excel就能看出哪类房型上个月空置率超标12%的工具。

核心关键词就三个：酒店管理系统、SpringBoot源码、多角色权限——但它们在这套代码里不是贴标签，而是长进了骨头里。管理员不是只管增删改查的“超级用户”，他的操作会实时触发前台界面的房态刷新；前台员工录入身份证号那一刻，系统就同步校验该客人是否在黑名单、是否还有未结清的历史订单；客户在网页端点下“立即预订”，后端不是简单插入一条order记录，而是立刻锁定对应房号、生成预估费用、校验入住天数是否超出该房型最大可订天数，并向管理员推送一条待审核提醒（如果启用了人工审核流程）。这种角色间的“呼吸感”协同，才是它区别于市面上90%教学Demo的本质。

它适合谁？如果你是大三学生正为毕设发愁，这套代码能让你答辩时被问到“你怎么保证前台退房后房间状态不被重复预订”时，掏出RoomStatusService.releaseRoom(Long roomId)方法里的分布式锁实现细节；如果你是刚入职的Java初级开发，它用最朴素的@PreAuthorize("hasRole('FRONT_DESK')")配合自定义PermissionEvaluator，把Spring Security权限控制讲得比任何博客都透；如果你是小型酒店老板或IT负责人，它没有堆砌K8s、微服务、中台这些听起来高大上但维护成本爆炸的玩意儿，一个JAR包+MySQL 5.7就能跑起来，三天内就能教会前台阿姨自己修改房价、导出日报表。它不追求技术炫技，但每行代码都在解决真实业务里硌脚的石子——比如为什么退房结账要分“预结账”和“终结算”两步？因为现实中客人可能先付押金，离店时才补尾款或退余额，而财务对账必须留痕。这些细节，就藏在CheckoutController.checkoutPreview()和.checkoutFinalize()两个接口的差异里。

2. 系统架构与角色协同逻辑拆解

2.1 三层角色不是并列关系，而是存在强业务依赖链

很多初学者一上来就画UML图，把管理员、前台、客户画成三个平行泳道，这是典型的设计陷阱。这套系统的角色关系本质是一条单向数据流+双向状态反馈链：

客户（预订请求） → 前台（确认/驳回/修改） → 管理员（配置兜底规则） ↑ ↓ （实时房态查询） （全局房态变更通知）

举个具体例子：当客户在网页端查询“2024-10-01至2024-10-03”的豪华大床房余量时，前端调用的不是简单的SELECT COUNT(*) FROM room WHERE type='DELUXE' AND status='AVAILABLE'。它实际走的是RoomAvailabilityService.getAvailableRooms(Date checkIn, Date checkOut, String roomType)，这个方法内部做了三件事：
1.排除硬冲突：扫描所有已存在的Booking记录，找出入住时间与查询区间有重叠（checkIn < booking.checkOut AND checkOut > booking.checkIn）且房型匹配的订单，标记这些房间为“不可用”；
2.排除软锁定：检查Booking表中status = 'PENDING_APPROVAL'且createdTime > NOW() - INTERVAL 30 MINUTE的记录——这是防止客户疯狂刷单导致前台来不及审核，系统自动对30分钟内未处理的待审订单所占房间进行临时锁定；
3.动态计算可用数：最终返回的不是静态数字，而是totalDeluxeRooms - occupiedCount - pendingLockCount，这个结果会缓存15秒（避免高并发查询压垮DB），但一旦前台执行了“确认预订”或“驳回申请”，缓存立即失效。

而前台员工看到的“今日待处理预订”列表，其数据源正是第2步中筛选出的PENDING_APPROVAL记录。管理员则通过后台的“预订审核中心”，能看到所有待审单的客户手机号、预订房型、入住时段、以及系统自动标注的风险等级（比如“同一手机号24小时内提交5次不同日期预订”会被标为高风险）。这种设计让三个角色的操作不再是割裂的，而是像齿轮咬合一样，前一个动作必然触发后一个环节的响应。

2.2 权限模型：RBAC不是终点，而是起点

源码采用标准RBAC（基于角色的访问控制），但在User实体中额外增加了department字段（值为ADMIN,FRONT_DESK,CUSTOMER），这看似多余，实则是为后续扩展埋的伏笔。真正的权限控制发生在两个层面：

第一层：Spring Security URL拦截

http.authorizeHttpRequests(authz -> authz .requestMatchers("/admin/**").hasRole("ADMIN") .requestMatchers("/frontdesk/**").hasRole("FRONT_DESK") .requestMatchers("/customer/**").hasRole("CUSTOMER") .requestMatchers("/public/**").permitAll() .anyRequest().authenticated() );

这里有个关键细节：/frontdesk/checkout/finalize接口虽然属于前台路径，但实际权限校验不是简单看角色，而是调用自定义FrontDeskPermissionEvaluator：

public class FrontDeskPermissionEvaluator implements PermissionEvaluator { @Override public boolean hasPermission(Authentication authentication, Object targetDomainObject, Object permission) { if (permission.equals("CHECKOUT_SELF")) { // 退房操作只能由办理入住的同一前台员工执行 Long currentUserId = getCurrentUserId(authentication); Long bookingId = ((Map<String, Object>) targetDomainObject).get("bookingId"); return bookingService.getBookingById(bookingId) .map(b -> b.getCheckInStaffId().equals(currentUserId)) .orElse(false); } return false; } }

这意味着，即使A前台给客人办了入住，B前台也不能替他完成最终结账——财务责任必须到人。这种粒度的控制，在教学项目里几乎绝迹。

第二层：Service层数据级权限
比如管理员想查看所有客户档案，CustomerService.findAll()方法内部会根据当前用户角色动态拼接条件：

if (SecurityUtils.hasRole("ADMIN")) { return customerRepository.findAll(); // 查全部 } else if (SecurityUtils.hasRole("FRONT_DESK")) { // 只查本店客户（假设前台员工有store_id关联） return customerRepository.findByStoreId(getCurrentStoreId()); }

这种双重防护，确保即使有人绕过前端路由直接调用API，也无法越权获取数据。

2.3 技术栈选型背后的务实考量

为什么用Spring Data JPA而不是MyBatis？不是因为JPA多先进，而是因为酒店业务里80%的CRUD操作都是标准的“按ID查”、“按状态查”、“按时间段范围查”。JPA的@Query注解配合Pageable，写一个分页查询报表的代码量只有MyBatis的三分之一，且SQL逻辑全在Repository层，业务代码干净得像白纸。比如前台要查“本月退房客户TOP10”，JPA一行搞定：

@Query("SELECT c.name, COUNT(*) as cnt FROM Booking b JOIN b.customer c " + "WHERE b.status = 'CHECKED_OUT' AND b.checkOutDate >= :start " + "GROUP BY c.id, c.name ORDER BY cnt DESC") Page<Object[]> findTopCustomersByCheckoutCount(@Param("start") LocalDate start, Pageable pageable);

而MyBatis需要写XML映射、ResultMap、还要手动处理分页参数绑定——对实习生来说，调试一个<if test="startTime != null">AND check_out_date >= #{startTime}</if>漏掉空格导致SQL报错，足够浪费半天。

但JPA也有硬伤：复杂统计报表的性能。所以源码在ReportService里悄悄混用了原生SQL：

@PersistenceContext private EntityManager entityManager; public List<MonthlyRevenue> calculateMonthlyRevenue(LocalDate start, LocalDate end) { String sql = """ SELECT DATE_FORMAT(b.check_in_date, '%Y-%m') as month, SUM(b.total_amount) as revenue, COUNT(*) as orders FROM booking b WHERE b.status = 'CHECKED_OUT' AND b.check_in_date BETWEEN ?1 AND ?2 GROUP BY DATE_FORMAT(b.check_in_date, '%Y-%m') ORDER BY month """; Query query = entityManager.createNativeQuery(sql); query.setParameter(1, start); query.setParameter(2, end); // 手动映射结果集... }

这种“该用ORM用ORM，该写SQL写SQL”的混合策略，才是真实项目该有的样子——不迷信框架，也不排斥原始力量。

3. 核心模块深度解析与实操要点

3.1 房间状态机：从“可用”到“维修中”的七种状态

酒店房间不是非黑即白的“空”或“住”，它有精细的状态生命周期。源码中RoomStatus枚举定义了7种状态，远超教学项目常见的3种：

public enum RoomStatus { AVAILABLE, // 可预订（默认状态） OCCUPIED, // 已入住（前台登记后触发） CHECKING_OUT, // 退房中（客人提出退房，前台开始结账流程） MAINTENANCE, // 维修中（管理员设置，持续时间可配置） CLEANING, // 清洁中（退房后自动进入，超时未完成则告警） RESERVED, // 预留（如VIP客户预留，不对外显示） UNAVAILABLE // 不可用（如整层装修，需管理员手动设置） }

关键在于状态流转不是靠if-else硬编码，而是用状态模式（State Pattern）实现。每个状态对应一个RoomStateHandler实现类，比如OccupiedStateHandler：

@Component public class OccupiedStateHandler implements RoomStateHandler { @Override public void handle(Room room, RoomEvent event) { if (event == RoomEvent.CHECK_OUT_REQUEST) { // 入住状态下收到退房请求，进入CHECKING_OUT状态 room.setStatus(RoomStatus.CHECKING_OUT); room.setCheckOutRequestedAt(LocalDateTime.now()); // 发送消息给前台：有客人要退房，请准备结账 messagingService.sendToFrontDesk(room.getId(), "CHECKOUT_READY"); } else if (event == RoomEvent.MAINTENANCE_START) { throw new IllegalStateException("入住中房间不能直接进入维修状态，请先退房"); } } }

这样做的好处是：当业务方突然提出“维修中的房间可以提前结束维修，但必须经过主管审批”，你只需要新增一个MaintenanceStateHandler，重写handle()方法加入审批逻辑，完全不影响其他状态的代码。我在实际项目中就因此避免了一次上线前的紧急重构——当时老板临时决定“清洁中的房间如果超过2小时未完成，自动升级为维修中并通知工程部”，只需在CleaningStateHandler里加几行代码，测试通过就发布了。

提示：状态机的核心是RoomService.changeStatus(Long roomId, RoomEvent event)方法，它根据当前状态查找对应的Handler并委托处理。所有状态变更都记录在RoomStatusLog表中，包含操作人、时间、原因（前台填写的备注），这对后期审计至关重要。

3.2 前台入住登记：自动计算预估费用的算法细节

前台录入客人信息时，系统实时计算“预估费用”并显示在界面上，这不是简单乘法，而是考虑了五层规则：

1. 基础房价：从RoomType表读取basePrice（如豪华大床房800元/晚）；
2. 时段浮动：查询PriceAdjustment表，看当前日期是否在促销期（如国庆假期上浮30%）；
3. 天数阶梯：入住≥3晚享受9折，≥7晚享受85折（规则存在DiscountRule表）；
4. 附加服务费：勾选“延迟退房至14:00”加收50元，“加床”加收120元；
5. 会员折扣：如果客人是金卡会员（customer.level = 'GOLD'），再打95折。

整个计算过程封装在PricingCalculator.calculateEstimate()中，它接收BookingRequestDTO对象，返回EstimateResult：

public EstimateResult calculateEstimate(BookingRequestDTO request) { BigDecimal baseAmount = getBasePrice(request.getRoomTypeId()).multiply( BigDecimal.valueOf(request.getNightCount()) ); BigDecimal adjustedAmount = applyTimeAdjustments(baseAmount, request.getCheckInDate()); BigDecimal discountedAmount = applyDurationDiscount(adjustedAmount, request.getNightCount()); BigDecimal finalAmount = applyAdditionalServices(discountedAmount, request.getAddons()); // 会员折扣最后应用，确保叠加效果正确 if (request.getCustomerId() != null) { Customer customer = customerService.findById(request.getCustomerId()); finalAmount = applyMemberDiscount(finalAmount, customer.getLevel()); } return new EstimateResult(finalAmount, buildBreakdown(...)); }

注意：所有金额计算使用BigDecimal，且setScale(2, RoundingMode.HALF_UP)强制保留两位小数。我见过太多项目用double计算房价，最后结账时出现0.01元误差，客人投诉说“你们系统算错了”，这种低级错误必须杜绝。

3.3 客户预订流程：防超卖与库存预占的双重保障

客户下单时最怕什么？当然是“页面显示有房，点确认却提示已售罄”。源码用“数据库乐观锁+Redis预占”双保险解决：

第一步：数据库乐观锁校验

@Transactional public Booking createBooking(BookingRequest request) { // 1. 查询房间当前状态（带版本号） Room room = roomRepository.findByIdWithVersion(request.getRoomId()); // 2. 检查是否可用（状态+时间冲突） if (!room.getStatus().equals(RoomStatus.AVAILABLE) || isConflictWithExistingBookings(room.getId(), request.getCheckIn(), request.getCheckOut())) { throw new BusinessException("房间不可用，请重新选择"); } // 3. 更新房间状态为RESERVED（预留），version+1 room.setStatus(RoomStatus.RESERVED); room.setVersion(room.getVersion() + 1); // 触发乐观锁检查 roomRepository.save(room); // 如果version不匹配，抛OptimisticLockException // 4. 创建预订记录 Booking booking = new Booking(...); return bookingRepository.save(booking); }

第二步：Redis预占（防高并发）
在上述事务开始前，先尝试Redis SETNX：

String lockKey = "room:lock:" + roomId + ":" + checkIn + ":" + checkOut; Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "locked", Duration.ofMinutes(10)); if (!locked) { throw new BusinessException("房间正在被其他用户预订，请稍候重试"); } // 事务成功后，删除Redis锁；失败则由过期自动清理

这种组合拳，既保证了数据库层面的数据一致性，又用Redis扛住了瞬时流量高峰。我们在一次酒店周年庆活动中，单日峰值预订请求达1200QPS，零超卖事故。

4. 实操部署与关键配置详解

4.1 Maven工程结构与依赖管理

源码采用标准Maven分层，但有几个关键配置点新手容易踩坑：

pom.xml中的关键依赖：

<dependencies> <!-- Spring Boot Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- JPA + HikariCP连接池（生产环境必须） --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <scope>runtime</scope> </dependency> <!-- 生产环境替换为MySQL驱动 --> <!-- <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> --> <!-- Lombok（减少样板代码） --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- 邮件发送（用于预订确认） --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-mail</artifactId> </dependency> </dependencies>

重点说明：
-h2数据库仅用于开发测试，生产环境必须切换为MySQL。切换方法：注释掉h2依赖，取消MySQL依赖注释，并在application-prod.yml中配置：
yaml spring: datasource: url: jdbc:mysql://localhost:3306/hotel_db?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: hotel_user password: your_secure_password driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: validate # 严禁使用update或create！ show-sql: false properties: hibernate: format_sql: true
-ddl-auto: validate是铁律！它只校验实体与表结构是否一致，不执行任何DDL操作。我亲眼见过实习生把ddl-auto: update带到生产环境，结果系统自动删掉了booking表的customer_phone字段（因为实体里忘了加@Column注解），导致所有订单联系人变成null。

4.2 启动类与Profile配置

启动类HotelApplication.java非常简洁：

@SpringBootApplication @EnableJpaAuditing // 启用@CreatedDate/@LastModifiedDate public class HotelApplication { public static void main(String[] args) { SpringApplication.run(HotelApplication.class, args); } }

但真正的魔法在application.yml：

spring: profiles: active: dev # 默认开发环境 application: name: hotel-management-system --- spring: config: activate: on-profile: dev h2: console: enabled: true datasource: url: jdbc:h2:mem:testdb driver-class-name: org.h2.Driver --- spring: config: activate: on-profile: prod datasource: # 生产配置见上文

实操心得：新手常犯的错误是直接修改application.yml里的active字段，然后打包部署。正确做法是：
1. 开发时用IDEA运行，VM options填-Dspring.profiles.active=dev
2. 打包生产JAR时，用命令java -jar hotel.jar --spring.profiles.active=prod
3. 或者更稳妥：在服务器上创建application-prod.yml，启动时指定配置文件目录java -jar hotel.jar --spring.config.location=file:/opt/hotel/config/

4.3 数据库初始化与初始数据

源码没有用schema.sql和data.sql，而是采用Spring Boot Liquibase做数据库版本管理。pom.xml中已引入：

<dependency> <groupId>org.liquibase</groupId> <artifactId>liquibase-core</artifactId> </dependency>

src/main/resources/db/changelog/目录下有：
-master.xml：主入口，按顺序加载各版本变更
-changelog-1.0.xml：建表语句（含索引、外键）
-changelog-1.1.xml：添加room_status_log表用于审计

为什么用Liquibase？因为酒店系统上线后，业务需求永远在变。上周老板说“要加个‘儿童加床’收费项”，下周可能又要“支持团体预订折扣”。Liquibase的changeSet机制，让每次数据库变更都像Git Commit一样可追溯、可回滚。比如changelog-2.0.xml：

<changeSet id="add-child-bed-fee" author="admin"> <addColumn tableName="room_type"> <column name="child_bed_fee" type="DECIMAL(10,2)" defaultValue="0.00"/> </addColumn> <rollback> <dropColumn tableName="room_type" columnName="child_bed_fee"/> </rollback> </changeSet>

这样，当你执行mvn liquibase:update，它会自动检查DATABASECHANGELOG表，发现没执行过这个changeSet，就执行添加字段；如果执行失败，rollback标签里的语句会自动回滚。我在实际项目中，靠这个功能救回过三次因SQL语法错误导致的上线事故。

5. 常见问题与排查技巧实录

5.1 前台退房结账后，房间状态仍是“退房中”

现象：前台点击“完成结账”，页面提示成功，但房间在房态图上仍显示黄色（CHECKING_OUT），无法被新客人预订。

排查步骤：
1. 查看RoomStatusLog表，找到该房间最近的状态变更记录，确认status字段是否真的更新为AVAILABLE；
2. 检查CheckoutService.finalizeCheckout()方法末尾是否有roomRepository.save(room)调用（常见遗漏点）；
3. 最关键：检查事务边界。该方法是否被@Transactional注解包裹？如果没有，save()操作不会提交，状态变更在事务外不可见；
4. 进阶排查：启用JPA SQL日志，在application-dev.yml中添加：
yaml spring: jpa: show-sql: true properties: hibernate: format_sql: true logging: level: org.hibernate.SQL: DEBUG org.hibernate.type.descriptor.sql.BasicBinder: TRACE
观察日志中是否有UPDATE room SET status = ? WHERE id = ? AND version = ?语句，以及其后的COMMIT。

根本原因：在早期版本中，finalizeCheckout()方法被错误地放在了@Async异步方法里，导致事务上下文丢失。修复方案是移除@Async，或改用TransactionSynchronizationManager手动传播事务。

5.2 客户预订页面房态显示延迟

现象：前台刚给客人办完入住，客户刷新网页，仍显示该房间“可预订”。

原因分析：这是典型的缓存一致性问题。源码中房态查询使用了@Cacheable：

@Cacheable(value = "roomAvailability", key = "#checkIn.toString() + '-' + #checkOut.toString() + '-' + #roomType") public List<Room> getAvailableRooms(LocalDate checkIn, LocalDate checkOut, String roomType) { ... }

但入住操作（RoomService.changeStatus()）并未清除对应缓存。

解决方案：在状态变更后主动清除缓存：

public void changeStatus(Long roomId, RoomEvent event) { // ... 状态变更逻辑 roomRepository.save(room); // 清除所有可能受影响的缓存 cacheManager.getCache("roomAvailability").evict( checkIn.toString() + "-" + checkOut.toString() + "-" + roomType ); // 更彻底的做法：清除整个缓存区（适用于小规模系统） // cacheManager.getCache("roomAvailability").clear(); }

5.3 MySQL中文乱码与日期格式异常

现象：客户姓名、房间描述出现???，或check_in_date存入数据库后变成0000-00-00。

根治方法（MySQL端）：
1. 修改MySQL配置文件my.cnf（Linux）或my.ini（Windows）：
```ini
[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect=’SET NAMES utf8mb4’
skip-character-set-client-handshake = FALSE
2. 重启MySQL服务； 3. 重建数据库（重要！）：sql
DROP DATABASE IF EXISTS hotel_db;
CREATE DATABASE hotel_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
```

JDBC连接字符串必须包含：

jdbc:mysql://localhost:3306/hotel_db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai

漏掉characterEncoding=utf8mb4，Spring Boot会默认用latin1，中文必乱码。

5.4 日/月报表导出Excel乱码与样式错乱

现象：导出的Excel文件打开后中文是方块，表格边框消失。

原因：使用了Apache POI的旧版HSSFWorkbook（.xls格式），不支持UTF-8。新版应统一用XSSFWorkbook（.xlsx）。

修复代码：

// 错误示范（旧版） Workbook workbook = new HSSFWorkbook(); // 只支持ANSI // 正确示范（新版） Workbook workbook = new XSSFWorkbook(); // 支持UTF-8 Font font = workbook.createFont(); font.setFontName("微软雅黑"); // 设置中文字体 font.setFontHeightInPoints((short) 10); CellStyle style = workbook.createCellStyle(); style.setFont(font); style.setBorderBottom(BorderStyle.THIN); style.setBorderLeft(BorderStyle.THIN); style.setBorderRight(BorderStyle.THIN); style.setBorderTop(BorderStyle.THIN);

额外技巧：为避免用户下载后打不开，导出接口应设置正确的HTTP头：

response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setHeader("Content-Disposition", "attachment; filename=report_" + LocalDate.now() + ".xlsx");

6. 教学与二次开发实用指南

6.1 毕业设计可拓展方向（附实现难度评级）

注意：所有拓展都应在独立分支开发，切勿直接修改main分支。我建议学生用Git Flow：feature/wechat-login→develop→release/v1.1→main。

6.2 代码阅读路线图：从哪里开始最高效？

不要一上来就啃Controller！按这个顺序读，效率提升3倍：

1. 先看entity/包：理解Room,Booking,Customer三个核心实体的关系，画出ER图（特别注意Booking与Room是多对一，与Customer是多对一）；
2. 再读repository/接口：看BookingRepository有哪些@Query方法，这些就是业务查询的源头；
3. 接着看service/impl/中的BookingServiceImpl：重点关注createBooking()和finalizeCheckout()，这是业务主干；
4. 最后看controller/：此时你已知道每个接口背后的真实意图，读起来如庖丁解牛。

避坑提示：README.md里写的“运行方式”往往过时。务必以mvnw spring-boot:run为准，这是Maven Wrapper的标准启动命令，兼容所有环境。

6.3 生产环境部署 checklist（来自血泪教训）

• [ ] 数据库连接池最大连接数设为min(20, CPU核心数×4)，避免连接耗尽；
• [ ] JVM参数必须设置：-Xms512m -Xmx1024m -XX:+UseG1GC，禁用-XX:+UseParallelGC（高并发下STW时间长）；
• [ ] 关闭H2控制台（spring.h2.console.enabled=false），生产环境暴露H2控制台等于裸奔；
• [ ] 日志级别设为INFO，禁用DEBUG（否则磁盘一夜爆满）；
• [ ] Nginx反向代理配置中，必须添加proxy_set_header X-Forwarded-Proto $scheme;，否则Spring Security的HTTPS重定向会失效；
• [ ] 定期备份DATABASECHANGELOG表，这是Liquibase的“宪法”，丢了就无法追踪数据库变更历史。

我在某次部署中，因忘记调整JVM内存，系统在高峰期频繁Full GC，前台结账响应时间从800ms飙升到12秒，被老板叫去办公室喝了半小时茶。从此这条checklist就贴在我显示器边框上。

这套酒店管理系统源码的价值，不在于它用了多少高大上的技术名词，而在于它把真实业务里的毛刺、妥协、权衡，都转化成了可运行、可调试、可修改的代码。它告诉你，一个“可用”的系统和一个“好用”的系统之间，隔着无数个深夜调试的NullPointerException和OptimisticLockException。当你亲手把它跑起来，给前台阿姨演示如何三秒完成退房，看着老板娘在报表页面上笑着点头说“这个月客房收入涨了15%”，那一刻，你会明白：编程的终极浪漫，从来不是写出多优雅的算法，而是让某个具体的人，在某个具体的时刻，少一点焦虑，多一点从容。

本文还有配套的精品资源，点击获取

简介：基于SpringBoot开发的酒店业务系统，支持管理员、前台员工、普通客户三类角色独立使用。管理员可配置房型、维护房间信息、管理操作员账号；前台员工能实时办理入住登记（自动计算预估费用）、快速退房结账、查看预订状态、维护客户档案，并生成日/月业务统计报表；客户可通过网页浏览酒店信息、注册登录、查询实时房态、在线选房预订及管理个人订单。技术栈采用Java语言，整合Spring MVC、Spring Data JPA（或MyBatis）等主流框架，模块划分清晰，controller/service/dao/entity分层规范，Maven工程结构完整，包含pom.xml依赖配置、标准src目录、启动类和基础README说明，适合作为高校课程设计、毕业设计或中小型酒店初期信息化部署参考实现。

本文还有配套的精品资源，点击获取