Java Web酒店管理系统房态设计：状态机建模与服务端实践指南

从 2019 年到现在，我陆续带过不少计算机专业毕业设计，也看过大量“酒店管理系统”方向的代码。Java Web 酒店管理系统几乎算是毕设里的常青树，但真正能扛住答辩老师追问的却不多。这里最典型的问题，不是登录注册没写，也不是增删改查报错，而是很多人把“房态状态”做成了房间表里一个随随便便的字段：四个值一存，页面一标颜色，就以为完工了。一旦被问到“客人正在办入住，另一个前台同时点了预订，会怎样”“退房后房间真的应该立刻变空闲吗”，立刻就露馅。

这篇内容就是围绕一套基于 Java Web 的酒店管理系统里“空闲、已预订、已入住、清洁中”这四种房态的设计全过程来做复盘。我会把状态机的边界、数据库建模、服务端如何做状态流转、前端房态图怎么做，以及毕业设计里文档和答辩准备这些容易忽略的地方，全部串起来讲。它不是一篇纯理论科普，而是能直接拿去参考设计的完整思路，适合正在做毕设、或者想用 Java Web 栈写一个真正能落地项目的同学。

1. 先把问题拆清楚：四个房态不是四个颜色，而是一张状态流转网

1.1 四个状态的真正含义和边界

很多初学者一看需求文档就以为系统只需要做 0、1、2、3 四个数字对应四种状态。但作为开发者你需要先理解，这四个状态本质上不是在描述“房间现在长什么样”，而是在描述“这间房当前能不能被卖掉、前台能不能接待客人”。如果沿着这个思路去建模，很多边界问题会清晰很多。

我通常会在设计文档里把四个状态做这样定义：

这里有一个非常容易混淆的地方：已预订和已入住都表示“房间已经被占用”，但它们对应的业务单据是完全不同的。已预订对应的是预订订单，通常发生在前台通过电话、网络或线下预约未来某一天入住；已入住则对应的是入住登记单，表示客人在当前时刻真实占用了房间。这些状态不能互相替代，不能因为“都是被占了”就简单合并。

另一个细节是“空闲”状态不能随意写入。一间房从已入住退房之后，如果直接变成空闲，保洁阿姨可能根本不知道这间房需要打扫，最后就会出现“系统提示可售，但客人走进房间看到床单没换”的惨剧。正确做法是退房后先进清洁中，等客房部确认打扫完毕，再流转回空闲。这个点做设计时务必想清楚。

1.2 哪些流转合法，哪些必须拦截

状态设计最核心的不是列出来四种状态，而是把“合法流转路径”锁住。如果系统里任何状态都能改成任何状态，那后台的数据很快会变成一笔糊涂账。下面是我在项目里锁定的合法流转集合：

• 空闲 -> 已预订：前台给客人做预订，把房间预留下来。
• 空闲 -> 已入住：客人到店后没有提前预订，直接散客入住，系统应该支持这种一步到位。
• 已预订 -> 已入住：客人持预订单到店，办完入住手续后房间从“预订锁定”状态变成“实际占用”状态。
• 已预订 -> 空闲：客人取消预订，或者系统超时判定客人不到店，释放房间。
• 已入住 -> 清洁中：客人退房，房间需要保洁，不能直接变空闲。
• 清洁中 -> 空闲：保洁人员操作“打扫完成”，房间恢复可售。

反过来，下面这些流转必须被系统拦截：

• 已入住 -> 已预订：房间还住着人，不能再接受别人的预订。
• 已入住 -> 空闲：绕过保洁环节，会导致房间真实卫生状态与系统不一致。
• 清洁中 -> 已预订：还有一种特殊情况。可不可以让客人预订一间正在打扫的房间？在真实酒店里是可以的，比如客人下午到店，房间上午退出来正在打扫，前台可以把这间房先锁给客人。但在毕设系统里，如果做这种“预订清洁中房间”的逻辑，就需要额外处理保洁完成时间、客人到店时间，复杂度会明显上升。我建议第一版直接不允许，因为大多数答辩场景只需要把主流程闭环讲清楚。

如果一开始就把这张流转表定好，后面的 service 层代码、接口参数校验、前端按钮显示都会变得非常清晰：前端不是脑补该显示什么按钮，而是根据当前状态去查“这个状态下可以做哪些合法动作”。

1.3 为什么我建议把“当前房态”和“某日可售状态”分开理解

这里是一个容易被需求文档坑到的地方。有些酒店管理系统的需求里写着“预订房间后，房态变为已预订”，但这里没有区分两个时间维度：当前房间的真实状态，以及某个具体日期的可售状态。

最简单的理解方式：房间就像一节火车车厢。系统里记录的是“现在这节车厢里有人坐着吗、需要打扫吗”，而预订业务关注的是“明天这一站有没有人已经买票”。如果客人预订的是三天后入住，这间房第二天可能依然是空闲，仍然可以继续卖；到了入住日期那一天，房间才应该变成已预订状态。如果无论订的是哪一天，都立刻把房间状态改成已预订，那系统就会误伤正常的散客销售。

在毕设项目里，我建议把范围控制在一个合理的度：可以做“某日房态查询”或“未来日期预订记录”，但主界面那个总览房态图，维护的是房间的实时状态。开发文档里要主动说明这个设计取舍，并解释实时房态状态由前台操作触发，比如办理入住、退房、保洁完成，而预订单只在客人预订当天并且尚未入住时，才把实时房态置为已预订。这样一来，状态流转逻辑不会崩，答辩时还能体现你的业务洞察力。

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 '创建时间',
  update_time DATETIME NOT NULL COMMENT '修改时间',
  UNIQUE KEY uk_room_no (room_no)
) ENGINE=InnoDB COMMENT='房间表';

状态字段建议用 TINYINT 存数字，因为存储效率高，同时也方便程序里用枚举或常量类去映射。可能会有人推荐直接存字符串 FREE、BOOKED 这类英文值，看 SQL 时确实直观，但在 Java Web 项目里，字符串状态更容易因为大小写问题产生脏数据。你只要在 Java 代码里把数字和中文描述、英文标识的映射关系写清楚，就没有必要让数据库去承担可读性职责。

需要注意一点：房间号尽量加上唯一索引。这个细节很多人漏掉，第一版做的时候直接在页面上写房间号，结果插入重复房间数据，每次查房态都出现两条一样的 801，所有统计全错。加一个 UNIQUE KEY uk_room_no (room_no) 是最省事的兜底。

2.2 t_room_status_log：状态历史一定要留痕

房态模块最容易犯的一个错误，就是只维护房间表里的当前状态字段。这样一来，系统只能回答“现在房间是什么状态”，却回答不了“这间房今天经历了什么”。而前台出现纠纷、客人投诉、财务对账时，最需要的就是历史过程。

所以我强烈建议加一张 t_room_status_log 状态变更记录表，每发生一次状态变更就插入一条记录：

sql复制CREATE TABLE t_room_status_log (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  room_id BIGINT NOT NULL COMMENT '房间ID',
  room_no VARCHAR(10) NOT NULL COMMENT '房间号，冗余方便查询',
  old_status TINYINT NOT NULL COMMENT '变更前状态',
  new_status TINYINT NOT NULL COMMENT '变更后状态',
  change_type VARCHAR(30) NOT NULL COMMENT '变更类型：BOOK/CANCEL/CHECK_IN/CHECK_OUT/CLEAN',
  biz_order_no VARCHAR(32) DEFAULT NULL COMMENT '关联订单号/入住单号',
  operator_id BIGINT DEFAULT NULL COMMENT '操作人ID',
  operator_name VARCHAR(50) DEFAULT NULL COMMENT '操作人姓名',
  remark VARCHAR(255) DEFAULT NULL COMMENT '备注',
  create_time DATETIME NOT NULL COMMENT '创建时间',
  INDEX idx_room_id_time (room_id, create_time),
  INDEX idx_biz_order_no (biz_order_no)
) ENGINE=InnoDB COMMENT='房间状态变更日志表';

这张表的妙处有两点。第一，它是审计链路，谁在什么时间把哪间房从“空闲”改成了“已入住”，一切可追溯；第二，它能在答辩时成为明显的加分项，因为很多同期项目根本不会考虑到状态留痕。你真把这张表设计出来，并在代码里保证每次变更都写日志，评委很容易看出你不是只照着增删改查做作业。

从查询角度看，你还可以做一个“某间房的动态历史”页面：点开房间卡片，下方显示房态变化时间线。这个功能前端实现难度很低，但能有效撑起系统“可运营”的形象。

2.3 与订单、入住单、保洁单逻辑关系的规划

房间状态的变化很少是自己单独完成的，它通常伴随业务单据的创建或更新。这里需要想清楚到底哪些表承担上游职责。以我的经验，最少要理清三条关系链：

第一，预订链路。客人提交预订单，先创建 t_reserve_order 预订单，同时如果预订日期是当天或者次日马上入住，并且房间当前为空闲，就把房间状态从空闲改为已预订，状态日志里关联这张预订单的订单号。客人取消时反过来，先把预订单状态改成已取消，再把房间释放为空闲。

第二，入住链路。前台办理入住，可能有两种场景：客人已经预订，系统根据预订单找到对应房间，把房态从已预订改为已入住；客人没有预订，那就在入住登记时创建 t_check_in 入住单，同时把空闲房间改成已入住。入住单至少应该记录房间号、客人姓名、证件号、预计离店日期、实际入住时间、操作人。

第三，退房与保洁链路。客人退房会生成退房记录并计算房费，此时房间状态变成清洁中。这里我并不建议单独为每间房实时创建一张保洁任务表然后循环判断，因为毕设的保洁复杂度并不需要走到工人抢单那一步。更务实的方式是：维护一个 t_clean_task 表，记录房间进入清洁中的时间、保洁负责人、完成时间、备注。房间变更为“空闲”的唯一触发方式，就是保洁员将这个任务标记为完成。

到这里你可能已经发现，房态表本质上是所有业务操作的“结果”，它不应该被单独直接修改。开发新功能时一定要守住这个原则，否则后台业务卡片和房态图之间很容易出现不一致。

2.4 并发环境下防止“一房多卖”的两条防线

并发问题在单机演示时往往看不出来，但在真实酒店里两个前台同时接待客人时非常致命。最简单可靠的方案是用数据库条件更新，配合版本号。乐观锁的核心是更新时带上旧状态和版本号条件，如果影响行数为 0，说明在你操作期间已经被别人改掉，此次操作需要失败并提示前端刷新。

sql复制UPDATE t_room
SET status = #{newStatus}, version = version + 1, update_time = NOW()
WHERE id = #{roomId}
  AND status = #{oldStatus}
  AND version = #{oldVersion};

当两个前台同时点击“办理入住”时，这两个请求都会先查询到房间状态是空闲、版本号是 0。第一个请求执行 update，把版本号改成 1，第二个请求再去执行同样的 update 时，因为 version = 0 这个条件已经匹配不到数据，更新行数为 0，程序就能捕捉到冲突，返回“该房间刚刚已被占用，请刷新房态”。这套思路代码量不大，效果却立竿见影。

不过，仅靠乐观锁还不够。如果你的系统还需要校验“客人在同一时间段不能重复预订同一间房”，就必须在订单写入层面加以控制。以订单角度来说，合理的防线是给预订单的“房间号 + 入住日期 + 有效状态”建立唯一约束或加事务锁查询。这里需要特别说明，Database 唯一索引无法直接对“日期范围内重叠”这种逻辑做约束，所以更常用的手段是在创建订单的事务内，用 SELECT ... FOR UPDATE 锁住目标房间行，再判断该时间段是否冲突。具体脚本就不过度展开了，能理解这条防线逻辑，在答辩里讲出来就已经足够出彩。

3. 服务端落地：状态变更的强校验、事务边界与并发兜底

3.1 用枚举替代魔法数字

后端代码里最影响可读性的就是到处出现 if (room.getStatus() == 1) 这样的魔法数字。过一个月连自己都看不懂，更别说是毕业设计要给人讲。这里我建议定义一个统一的枚举类：

java复制public enum RoomStatus {

    FREE(0, "空闲"),
    BOOKED(1, "已预订"),
    CHECKED_IN(2, "已入住"),
    CLEANING(3, "清洁中");

    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;
    }

    public static RoomStatus of(int code) {
        for (RoomStatus status : values()) {
            if (status.code == code) {
                return status;
            }
        }
        throw new IllegalArgumentException("非法房态: " + code);
    }
}

服务层拿到 dao 返回的状态码后，先转成枚举再做判断，这样即使以后增加了“维修中”“锁房”等状态，改动范围也非常可控。枚举里还可以继续扩展状态图相关方法，比如 canTransferTo(RoomStatus target)，状态校验逻辑收拢在一个类里，调用方不需要知道状态机内部规则。

3.2 一个 checkIn 方法里的完整动作

状态变更不能只做一件事。以“办理入住”为例，它至少包含三个动作：更新房间状态为已入住、创建入住登记单、写入房态变更日志。这三个动作必须处于同一个事务里。我用一段简化代码来说明这个流程：

java复制@Transactional(rollbackFor = Exception.class)
public void checkIn(CheckInRequest request) {
    // 1. 查询房间，并使用悲观锁防止并发操作
    Room room = roomMapper.selectByIdForUpdate(request.getRoomId());
    if (room == null) {
        throw new BizException("房间不存在");
    }
    RoomStatus current = RoomStatus.of(room.getStatus());
    if (current == RoomStatus.CHECKED_IN) {
        throw new BizException("该房间已入住");
    }
    if (current == RoomStatus.CLEANING) {
        throw new BizException("该房间正在清洁中，不能办理入住");
    }

    // 2. 创建入住单，并处理订单关联
    CheckInRecord record = new CheckInRecord();
    record.setRoomId(room.getId());
    record.setReserveOrderId(request.getReserveOrderId());
    record.setGuestName(request.getGuestName());
    record.setIdCard(request.getIdCard());
    record.setCheckInTime(new Date());
    checkInRecordMapper.insert(record);

    // 3. 无条件状态变更改为条件更新，防止并发覆盖
    int rows = roomMapper.compareAndSetStatus(
            room.getId(),
            current.getCode(),
            RoomStatus.CHECKED_IN.getCode(),
            room.getVersion());
    if (rows == 0) {
        throw new BizException("房间状态已变化，请刷新后重试");
    }

    // 4. 如果来自预订单，则同步更新预订单状态
    if (request.getReserveOrderId() != null) {
        reserveOrderMapper.updateToCheckedIn(request.getReserveOrderId());
    }

    // 5. 写入状态变更日志
    roomStatusLogMapper.insert(RoomStatusLog.create(room.getId(), room.getRoomNo(),
            current.getCode(), RoomStatus.CHECKED_IN.getCode(),
            "CHECK_IN", request.getReserveOrderId(), request.getOperatorId()));
}

这里有几个容易被忽略的点。第一，状态更新的 SQL 条件和代码里查到的状态不一定一致，所以需要把 current 作为 update 条件，而不是直接更新。第二，创建入住单和更新房间状态如果分属两个事务方法，中途断电可能造成“入住单已经建好但房间状态仍为空闲”这种脏数据，所以整个流程必须注解 @Transactional。第三，如果预订单来自网上下单，也要同步把订单置为“已入住”，保证前端列表上的订单状态和房态图一致。

退房和保洁完成的逻辑和上面类似。退房主要把房间从已入住改成清洁中，并创建退房记录；保洁完成则是把清洁中改成空闲，并更新保洁任务状态。

3.3 超时未入住的定时释放

不是所有“已预订”都会顺利变成“已入住”。很多客人下单后并不会出现，如果系统不及时释放预订房间，会造成极大的资源浪费。为了毕设系统的完整性，这里可以引入一个后台定时扫描任务。

一般业务规则可以设计为：预订当日的保留时间到当天某个时间点，比如 18:00；如果到时仍未办理入住，系统自动取消这张预订单并释放房间。实现上可以用 Spring 自带的 @Scheduled：

java复制@Scheduled(cron = "0 */5 * * * ?")
public void autoReleaseTimeoutReservations() {
    List<ReserveOrder> timeoutOrders = reserveOrderMapper.selectTimeoutReservations(new Date());
    for (ReserveOrder order : timeoutOrders) {
        try {
            int rows = roomMapper.compareAndSetStatus(
                    order.getRoomId(),
                    RoomStatus.BOOKED.getCode(),
                    RoomStatus.FREE.getCode(),
                    0); // version 放开为任意值，用 status 作为条件即可
            if (rows > 0) {
                reserveOrderMapper.updateToCancelled(order.getId(), "18:00未到店，系统自动取消");
                roomStatusLogMapper.insert(...);
            }
        } catch (Exception e) {
            log.error("自动释放房间失败, orderId={}", order.getId(), e);
        }
    }
}

需要提醒的是，定时扫描的粒度不要太密，5 分钟一次已经足够；如果每秒钟扫一次，系统负载会成倍增加。这里的选择和参数都可以写进文档，作为系统设计的一部分。放到答辩里就是“业务规则设计”的加分项。

4. 前端房态图的实现思路：从 JSP 渲染到 jQuery 局部刷新的取舍

4.1 房态总览页的布局与颜色语义

酒店前台的房态页面往往需要一眼看全一整层或整栋楼的房间状态，所以布局通常采用网格卡片形式：每一行代表一个楼层，每个卡片代表一个房间。卡片内部显示房间号、状态中文描述，可能还有当前客人名字和预计离店时间。四种状态的视觉语义建议这样定：

• 空闲：绿色，表示可以直接售卖。
• 已预订：深黄色，表示被锁定但客人没有到店。
• 已入住：红色，表示房间里有人。
• 清洁中：浅灰色，或有进度感，表示等待保洁。

在页面顶部最好放一个图例，并且补充说明状态位维护的是实时状态，而不是简单的颜色区别。用 CSS 类控制颜色，不要用内联 style 硬编码。比如：

html复制<div class="room-card room-booked" data-room-id="101" data-status="1">
    <div class="room-no">101</div>
    <div class="room-status">已预订</div>
    <div class="room-guest">张先生</div>
</div>

这里建议状态描述在服务端或 JS 中根据状态码统一转义，而不要直接在 JSP 页面写死颜色的样式。因为以后要增加维修状态时，只需要加一个 CSS 类，不需要每个页面改颜色。

4.2 点一下卡片就完成切换

房态图页面里最频繁的操作是状态切换。早期我见过不少同学直接写一个“修改房态”的独立表格页面，前台需要跳出房态总览去提交表单。这种设计在实际操作中非常低效。更贴近真实酒店前台的做法是点击对应卡片，在弹出的操作面板里选择需要的业务动作。

以空闲房间卡片为例，点击后弹出的操作项应该是“办理入住”和“新建预订”。已预订房间则显示“办理入住”和“取消预订”。已入住房间显示“办理退房”。清洁中房间显示“保洁完成”。也就是说，前端能执行什么动作，由房间当前状态决定，按钮本身就不应该把非法操作展示出来。

如果项目里已经引入 jQuery，那么异步刷新是非常简单的方式：

javascript复制function handleRoomAction(roomId, actionType) {
    $.ajax({
        url: ctx + '/room/action',
        type: 'POST',
        data: {
            roomId: roomId,
            actionType: actionType, // CHECK_IN / CHECK_OUT / CLEAN_DONE / CANCEL_BOOKING
            remark: $('#remark').val()
        },
        dataType: 'json',
        success: function (res) {
            if (res.code === 200) {
                refreshRoomCard(roomId);
                showTip('操作成功');
            } else {
                showTip(res.msg);
            }
        }
    });
}

成功回调里只刷新对应卡片，不要整页刷新，这样界面体验才在线。尤其当房态页面上有多个房间、操作耗时较长时，局部刷新能避免页面闪烁。

4.3 前端交互中易被忽略的状态判断

写前端时还有一个非常容易踩的点：页面加载后长时间不操作，此时后台的房态可能已经被别的前台改掉了，如果用户仍然根据旧界面的状态去操作，就可能触发后台校验错误。所以前端不仅在页面初始化时要加载房态，每次弹出操作面板时最好也重新请求一次房间详情，或者在后端做条件更新后把冲突信息原样返回给用户。这样可以闭环处理并发问题，也更贴近真实收银系统“提交时校验，冲突就提示刷新”的原则。

另外，如果你使用的是纯 JSP，要注意页面里尽量避免大段 <% ... %> Java 代码去做循环渲染。建议在 JSP 里只放一个占位容器，页面加载后用 jQuery 调接口获取房态数据，再通过 JS 生成 HTML。这样代码结构清楚，而且后续如果要改造成前后端分离，前端部分几乎不用重写。

5. 毕业设计视角：文档、查漏与答辩脚本怎么准备

5.1 需求阶段把状态图画对

很多同学拿到酒店管理系统题目后，第一件事是打开 IDE 建表，这是本末倒置。毕业设计文档里，最重要的图往往不是 ER 图，而是房间状态图。因为 ER 图大家都会画，而一张状态图能非常直观地体现你是否真正理解业务。在需求分析阶段，我建议你在文档里画一张“房间状态流转图”，节点是空闲、已预订、已入住、清洁中，边上标注触发动作。

这张图同时会反哺开发：它能让系统里的每一条流转规则都有据可查，而不是程序员拍脑袋决定。比如“退房后为什么不是立刻变成空闲，而是清洁中”，这是你在答辩中一定能讲清楚的设计亮点。不要小看这一点，多数毕设作品都没有这个意识。

5.2 演示时能应对追问的三段式脚本

答辩演示不能直接把页面从头到尾点一遍，那样时间不够信息也散。比较稳的思路是演绎完一整条业务线，并且拿这条业务线把房态的完整生命周期串起来。

主线可以这样设计：当前系统里有几个空闲房间 → 前台办理一间房的预订 → 房间变成已预订 → 客人到店，点击办理入住 → 房间变成已入住 → 过了几天客人退房 → 房间变成清洁中 → 保洁人员操作完成清洁 → 房间变回空闲 → 最后去“状态日志”页面展示这间房的历史流转记录，证明所有变化都有迹可循。

演示时还有两个细节值得注意。一是不要提前把数据清空成一屏绿色，那样看着像演示系统；更好的方式是预置几种房态数据，让评委直观看到不同颜色代表不同状态。二是在演示过程中尽量自然地把第二步的“预订——入住——退房”串到“订单状态变化”上，让评委看到订单状态和房态不是各管各的。比如“订单已确认”对应房态已预订，办理入住后订单也变成“已入住”，退房结账后订单变成“已完成”，同时房态变成清洁中。这种“表和表之间的联动”是不是真的做扎实了，答辩评委几乎一眼就能看出来。

5.3 功能扩展方向与范围控制

我经常看到学生一上来就想做会员系统、报表统计、微信小程序、数据分析，最后全部堆在一起，核心模块却漏洞百出。毕业设计最忌贪多。如果你的核心目标是体现能力，建议优先把一个闭环做深，而不是贪图功能列表的表面完整。

如果时间确实充裕，可以考虑给房态模块做这些轻量扩展：

• 增加“维修中”状态：在房间主状态里加一个枚举，并修改流转校验规则即可。
• 增加楼层筛选和房型分组：让房态总览页适应不同规模的酒店。
• 增加房态使用率统计小报表：统计空闲、已入住、清洁中的房间数量，按天/小时记录变化。
• 把状态日志异步写入数据库：在并发量高时不影响主流程，但这对于毕设来说有些过度，但可以在文档里作为优化方向提及。

需要注意的是，扩展功能要建立在主流程稳固的前提上，否则每增加一个功能都会引入新的状态不一致风险。

6. 调试和上线前最容易踩的五个坑

6.1 已入住房间能被取消预订

这是很常见的状态校验漏洞。很多人的实现是：页面“取消预订”按钮会把房间直接改成空闲，却没有判断房间到底处于什么状态。于是可能出现这样的脏数据：801 房间已经被另一位客人住进去了，然后后台某个残留操作把这个房间的预订单一取消，房间状态立刻被改成空闲，下一次前台就可能把它又卖给新人。修复方式很朴素，却极其有效：所有状态更新方法里，先查询当前房间状态，再通过条件 UPDATE 保证只有符合预期状态的记录才会被更新。也就是说，“能取消预订”这个动作必须显式建立在“房间当前是已预订”的前提下。

6.2 退房直接变空闲，保洁流程完全失控

我在前面反复强调这个设计：退房后的状态应该是清洁中而不是空闲。实际开发时，很多人的退房操作只是把订单状态改成“已退房”，同时顺手把房间改成空闲，完全忽略了保洁环节。这样会导致保洁人员的任务列表里没有这个房间，房态图上却已经显示成绿色可售，最终造成客房卫生事故。正确逻辑必须让退房变成“清洁中”的唯一触发源头，保洁完成再恢复空闲。如果流程记录显示 801 房间早上 9 点退房，9 点 05 分就变成空闲，那就一定要检查是不是保洁被绕过了。

6.3 多个请求同时改同一间房，后提交的把先提交的覆盖

单用户点击时很难暴露这个问题，但毕设答辩现场有时老师会故意让你开两个浏览器窗口模拟两个前台同时操作。如果服务端代码没有做并发控制，两个窗口都看到 801 空闲，同时提交“办理入住”，两条 SQL 都可能会直接执行成功，最后入住单建出来两份。我前面的方案是让状态更新使用条件 UPDATE，确保只有一个事务能成功。这里需要确认一件事：条件 UPDATE 必须包含旧状态或版本号条件，否则即使加了事务注解，两个请求也都可能逐条执行并互相覆盖。

6.4 状态日志不落库，出了问题无从查

只看房间表当前状态，不会意识到历史日志有多重要。但一旦状态被错误流转，比如客人投诉说“我下午办理入住后，系统却告诉下一个客人这间房已退房”，如果没有日志，想查清是谁、在什么时候、因为什么原因改了状态，几乎不可能。状态日志表的插入动作，不要只在正常业务流转里写；在定时释放、甚至管理员手动修正状态的时候，也要写入日志。日志保存的备注字段也很有用，比如“18:00 未到店系统自动释放”，这样日志时间线本身就是一份完整的业务说明。

6.5 把 Java 代码塞进 JSP 页面

最后是代码层面的坑。JSP 页面本身是做视图渲染的，但很多人会把数据库查询和 if else 判断都塞进 <% %> 脚本片段。刚开始页面少的时候还挺方便，一旦页面变多就极难维护。我在这个项目里采用的方案是 Controller 返回 JSON，页面用 jQuery 发 AJAX 请求渲染。这个方式在 JSP 时代非常实用，代码分层也干净。即使你是第一次接触 JSP 项目，也用不着学太花哨的前端框架，jQuery 已经足够。

从状态定义到数据库建模，再到服务端和前端的一整套设计，你会发现房态状态管理本质上不是在写几个 if 判断，而是在设计一套完整的状态机，再让所有业务动作都遵守这组规则。把这套规则真正想清楚，不仅酒店管理系统能落地，以后让你去做工单状态、审批流程、订单状态等系统，也会顺手不少。

我个人的做法是，先画状态流转图，再回头写代码，遇到不清楚的业务语义宁可去问需求方也不自己拍脑袋；这个习惯帮我省掉的返工量，远比想象中大。