呗老心眼极小从 2019 年到现在，我陆续带过不少计算机专业毕业设计，也看过大量“酒店管理系统”方向的代码。Java Web 酒店管理系统几乎算是毕设里的常青树，但真正能扛住答辩老师追问的却不多。这里最典型的问题，不是登录注册没写，也不是增删改查报错，而是很多人把“房态状态”做成了房间表里一个随随便便的字段：四个值一存，页面一标颜色，就以为完工了。一旦被问到“客人正在办入住，另一个前台同时点了预订，会怎样”“退房后房间真的应该立刻变空闲吗”，立刻就露馅。
这篇内容就是围绕一套基于 Java Web 的酒店管理系统里“空闲、已预订、已入住、清洁中”这四种房态的设计全过程来做复盘。我会把状态机的边界、数据库建模、服务端如何做状态流转、前端房态图怎么做，以及毕业设计里文档和答辩准备这些容易忽略的地方，全部串起来讲。它不是一篇纯理论科普，而是能直接拿去参考设计的完整思路，适合正在做毕设、或者想用 Java Web 栈写一个真正能落地项目的同学。
1. 先把问题拆清楚：四个房态不是四个颜色，而是一张状态流转网
1.1 四个状态的真正含义和边界
很多初学者一看需求文档就以为系统只需要做 0、1、2、3 四个数字对应四种状态。但作为开发者你需要先理解，这四个状态本质上不是在描述“房间现在长什么样”，而是在描述“这间房当前能不能被卖掉、前台能不能接待客人”。如果沿着这个思路去建模，很多边界问题会清晰很多。
我通常会在设计文档里把四个状态做这样定义：
| 状态 | 代码建议 | 业务含义 | 房间可售性 |
|---|---|---|---|
| 空闲 | FREE | 房间已清洁，随时可以接待客人入住 | 可售 |
| 已预订 | BOOKED | 已有客人预订单锁定该房间，客人尚未到店办理入住 | 不可售 |
| 已入住 | CHECKED_IN | 客人已经办完入住手续，正在使用房间 | 不可售 |
| 清洁中 | CLEANING | 客人已退房，客房服务员正在打扫或等待打扫 | 暂不可售，打扫后可恢复可售 |
这里有一个非常容易混淆的地方：已预订和已入住都表示“房间已经被占用”，但它们对应的业务单据是完全不同的。已预订对应的是预订订单，通常发生在前台通过电话、网络或线下预约未来某一天入住；已入住则对应的是入住登记单，表示客人在当前时刻真实占用了房间。这些状态不能互相替代，不能因为“都是被占了”就简单合并。
另一个细节是“空闲”状态不能随意写入。一间房从已入住退房之后，如果直接变成空闲，保洁阿姨可能根本不知道这间房需要打扫，最后就会出现“系统提示可售，但客人走进房间看到床单没换”的惨剧。正确做法是退房后先进清洁中，等客房部确认打扫完毕，再流转回空闲。这个点做设计时务必想清楚。
1.2 哪些流转合法，哪些必须拦截
状态设计最核心的不是列出来四种状态，而是把“合法流转路径”锁住。如果系统里任何状态都能改成任何状态，那后台的数据很快会变成一笔糊涂账。下面是我在项目里锁定的合法流转集合：
- 空闲 -> 已预订：前台给客人做预订，把房间预留下来。
- 空闲 -> 已入住：客人到店后没有提前预订，直接散客入住，系统应该支持这种一步到位。
- 已预订 -> 已入住：客人持预订单到店，办完入住手续后房间从“预订锁定”状态变成“实际占用”状态。
- 已预订 -> 空闲：客人取消预订，或者系统超时判定客人不到店，释放房间。
- 已入住 -> 清洁中：客人退房，房间需要保洁，不能直接变空闲。
- 清洁中 -> 空闲：保洁人员操作“打扫完成”，房间恢复可售。
反过来，下面这些流转必须被系统拦截：
- 已入住 -> 已预订：房间还住着人，不能再接受别人的预订。
- 已入住 -> 空闲：绕过保洁环节，会导致房间真实卫生状态与系统不一致。
- 清洁中 -> 已预订：还有一种特殊情况。可不可以让客人预订一间正在打扫的房间？在真实酒店里是可以的，比如客人下午到店，房间上午退出来正在打扫，前台可以把这间房先锁给客人。但在毕设系统里，如果做这种“预订清洁中房间”的逻辑，就需要额外处理保洁完成时间、客人到店时间，复杂度会明显上升。我建议第一版直接不允许，因为大多数答辩场景只需要把主流程闭环讲清楚。
如果一开始就把这张流转表定好，后面的 service 层代码、接口参数校验、前端按钮显示都会变得非常清晰：前端不是脑补该显示什么按钮，而是根据当前状态去查“这个状态下可以做哪些合法动作”。
1.3 为什么我建议把“当前房态”和“某日可售状态”分开理解
这里是一个容易被需求文档坑到的地方。有些酒店管理系统的需求里写着“预订房间后，房态变为已预订”，但这里没有区分两个时间维度：当前房间的真实状态，以及某个具体日期的可售状态。
最简单的理解方式：房间就像一节火车车厢。系统里记录的是“现在这节车厢里有人坐着吗、需要打扫吗”，而预订业务关注的是“明天这一站有没有人已经买票”。如果客人预订的是三天后入住，这间房第二天可能依然是空闲，仍然可以继续卖；到了入住日期那一天，房间才应该变成已预订状态。如果无论订的是哪一天，都立刻把房间状态改成已预订，那系统就会误伤正常的散客销售。
在毕设项目里，我建议把范围控制在一个合理的度：可以做“某日房态查询”或“未来日期预订记录”，但主界面那个总览房态图，维护的是房间的实时状态。开发文档里要主动说明这个设计取舍，并解释实时房态状态由前台操作触发，比如办理入住、退房、保洁完成，而预订单只在客人预订当天并且尚未入住时，才把实时房态置为已预订。这样一来，状态流转逻辑不会崩，答辩时还能体现你的业务洞察力。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库建模：房间表、状态日志表、业务单据的关联方式
2.1 房间表的状态字段怎么设计
房间表是整个系统的基础。表里的字段不需要特别多，但最基本的房号、房型、楼层、状态、版本号、创建时间、修改时间都应该有。下面是我常用的建表脚本，你可以直接作为参考：
sql复制CREATE TABLE t_room (
id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '房间主键',
room_no VARCHAR(10) NOT NULL COMMENT '房间号，如 801、1002',
room_type_id BIGINT NOT NULL COMMENT '房型ID，关联房型表',
floor_no INT DEFAULT NULL COMMENT '所在楼层',
status TINYINT NOT NULL DEFAULT 0 COMMENT '房态状态：0-空闲 1-已预订 2-已入住 3-清洁中',
version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
create_time DATETIME NOT NULL COMMENT '创建时间',
u