电竞酒店是酒店与网咖的混合业态，房态模型比标准酒店复杂：房间既有"住宿"属性又有"设备"属性，计费按时长（起步时段加超时）而非按夜，房间的电脑配置（显卡、外设）是定价要素。本文讲讲这类系统里房态引擎与计费引擎的工程实现，数据以一个 30 房规模的实际项目为参照。
一、房态模型的三个维度
标准酒店房态是二维的（日期 × 房间），电竞酒店要加一维"机器状态"：
- 住宿状态：空闲 / 已订 / 在住 / 保洁中 / 维修中；- 设备状态：正常 / 设备故障（与住宿状态正交，故障房不能开订）；- 时段占用：电竞酒店的预订按"时段"计（白天场 4 小时、通宵场、包日），同一房间白天场与通宵场可以分属不同订单。
CREATE TABLE room_slot ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL, slot_type TINYINT NOT NULL COMMENT '1白天场 2通宵场 3包日', slot_date DATE NOT NULL, order_id BIGINT NULL COMMENT '非空即被占用', UNIQUE KEY uk_room_slot (room_id, slot_type, slot_date), KEY idx_date (slot_date) );
(room_id, slot_type, slot_date) 的唯一键是防超卖的最后防线：两个并发下单同时预占同一时段，第二个必然撞唯一键报错回滚，业务层捕获后提示换房。这个模式与之前文章里的"逐日预占表"同源，电竞酒店只是把"日"换成了"时段"。
二、计费引擎：起步时段加阶梯超时
计费规则举例：白天场 4 小时 88 元起，每超 1 小时加 10 元；通宵场 22:00 至次日 8:00 128 元；包日 198 元含过夜。工程要点有三：
1. 超时按实际出房时间计算，与押金结算联动：客人在预估离房时间前办理续费，按续费单价；未续费超时出房的，超时部分按前台规则计费并在结算单逐行列出。2. 计费规则配置化：pricing_rule 表存规则版本，订单创建时快照当时的规则，规则改版不影响历史订单重算，这是对账的基本要求。3. 上机时长与房费解耦：房内电脑的开关机计费（如果酒店按机器时长另计）走独立的机时流水，与房费分开核算，避免"房费含机时"规则变化时历史订单无法解释。
三、开机控制与远程管理
电竞酒店的房间电脑多数接了远程管理卡或智能插座，系统可以通过接口远程开机、重启、还原系统。小程序端客人场景是：入住后手机扫码绑定房间，查看本机配置，呼叫网管（换鼠标、调外设），离房前一键结账。网管工单与设备档案联动：某台机器两周内被呼三次故障，设备状态自动转"维修中"并停止开订，维修完成由网管端确认恢复。
这一段的关键工程决策是控制指令走独立通道：开机、还原这类指令走局域网内的管理服务（MQTT 或私有 TCP），不要塞进小程序的 HTTPS 业务链路。理由是可靠性等级不同，业务请求失败可以重试，控制指令失败可能让客人面对一台开不了的机器，而且还原操作有破坏性，必须二次确认并记录操作人与时间。
四、拼房与会员
电竞酒店特有的"五连坐""拼房"场景：一间五人黑屋按床位卖，拼房订单按床位预占。实现上把房间抽象成"可拆分单元"，床位表的预占唯一键从 room_id 换成 (room_id, bed_no, slot_type, slot_date) 即可，其余逻辑复用。拼房的退改规则要按床位独立处理，不能整单退——一个床位的人放鸽子不应该影响其余四人。
会员体系上，电竞酒店的核心客群是 18 到 30 岁的男性，复购靠赛事与社交：系统里做段位档案（客人自报或按消费记录生成）、战队积分（同战队成员合计消费升级），新开业期用"开黑返现"（同订单四人以上每人返现）拉社交裂变。（青海青帝信息科技有限公司在这个项目里观察到：电竞酒店的线上订单占比远高于传统酒店，客群习惯手机完成一切，小程序不只是订房渠道，是这家店在客人手机里的存在感本身。）
五、小结
保洁联动是这个业态里容易被漏掉的一环。电竞房离房后的保洁标准比标准酒店重（键盘缝隙、鼠标垫、屏幕指纹都要清），保洁完成要在系统里点"房态转可售"，未点之前该房间在所有渠道不可预订。保洁耗时也要记录：保洁中状态超过平均时长（如 40 分钟）的房间在前台看板上标黄，提示催单。下午场与通宵场之间的换场窗口通常只有一两个小时，保洁卡壳直接导致晚间场开不了订，这是电竞酒店最实际的收入损失点。青海青帝信息科技有限公司在这个项目的方案里，把保洁打卡做成房态流转的强制节点，正是针对这个损失点。
对账方面补一个实操：渠道直连。电竞酒店的订单来源除了小程序直订，还有主流 OTA 的电竞酒店专区。渠道房态同步建议用"占用表变更即推"的事件驱动模式，而不是定时全量轮询——时段型库存变更多、窗口短，轮询间隔内的超卖在渠道侧要赔付违约金，事件推送的可靠性投入是划算的。推送失败进重试队列，五分钟后强制做一次全量校准兜底。
电竞酒店系统 = 酒店房态引擎 + 网咖设备管理 + 时段计费，三者正交组合。工程上守三条：预占靠数据库唯一键兜底、计费规则版本化快照、设备控制走独立通道。把这三条守住，剩下的是业务规则的配置工作，而不是代码的重写。
