直接答案：房型和房间是两个东西，混着建一定出错。房型是拿来卖的，比如「大床房」；房间是物理存在的，比如「301」。一间物理房可以按不同卖法挂进多个房型，一个房型也对应若干间具体房间。房态也不是「有没有房」这么简单，至少要分空房可用、已预订、在住、脏房、维修五种，每一种的流转条件要写死。判断一套住宿系统能不能用，就问它一个问题：明天 301 房能不能卖，如果不能，是因为什么。
核心结论速览
物理房和售卖房型必须是两张表。物理房记房间号、楼层、朝向、床型、可住人数、是否可加床；售卖房型记房型名、含早份数、取消政策、担保方式、可售上限。两张表靠映射关系连起来。合成一张表的后果是：房型一改名，历史订单里的房型信息跟着断链。
房态是状态机，不是下拉框。五种状态之间有固定的流转路径，「在住」不能直接跳「可用」，必须先退房变「脏房」，清洁完成才回「可用」。做成下拉框，前台图省事直接把在住改成可用，客人还没走房就被卖了。
锁房、停售、维修是三件事。锁房是「暂时不卖、到期自动释放」；停售是「这段日期一律不卖、必须全渠道生效」；维修是「物理房不可用、要等维修完成」。三者混在一个「不可用」选项里，事后没人说得清这间房为什么不能卖。
库存挂在「房型加日期」上，不挂在房间上。今天满房不代表明天满房，所以可售数是逐日维护的。按房间记库存的系统，跨日期的连住订单一来就露馅。
出过订单的房型只能下架不能删。删掉之后历史订单里的房型名变空值，对账、评价、投诉追溯全部断线。下架只影响新订单，历史数据完整保留。
一、房型乱了之后，现场会发生什么
场景一：前台说没房了，客人问哪个房型没房，答不上来。系统里只显示一个「今日剩余 0」，看不出是大床房卖完还是双床房卖完，也不知道是真空了还是被锁了。前台只能打电话问店长，客人在前台等着。
场景二：同一间房被卖两次。301 在系统里既挂在「大床房」下，又挂在「大床含早」下。两个房型的可售数各算各的，各卖一次，客人到店只剩一间。这类超卖在旺季几乎每天发生，而且事后查不出来是哪一步错的。
场景三：保洁收拾完了，前台不知道。客人退房，房态变成脏房；保洁打扫完在纸上打了个勾，但没人回系统点「清洁完成」。前台看到还是脏房，就让新客人等半小时，实际上房间早就好了。
场景四：维修房被卖出去。301 空调坏了，员工把它设成「锁房三天」。三天后锁房到期自动释放，系统认为可以卖，客人入住发现空调不制冷。锁房是有期限的，维修没有期限，这两件事不能用同一个开关。
场景五：房型改过名，去年的订单查不出房型。系统里房型是直接写死在订单上的，改成「豪华大床房」之后，去年的订单还显示旧名，做同比分析时两个名字各算一类。房型要有稳定的内部编号，展示名可以改，编号不能变。
这五个场景的共同点是：系统把「卖的东西」和「实际存在的房间」当成了同一个东西。一旦这两层混在一起，任何一次改价、改名、改房态都会同时污染另一层，出错之后也定位不到原因。
二、物理房、售卖房型和库存怎么建模
物理房表的字段。房间号（全店不重复，含楼栋前缀）、楼层、所属楼栋、床型（大床、双床、上下铺、榻榻米）、可住成人数、可住儿童数、面积、窗户类型（明窗、内窗、无窗）、朝向、是否可加床、最大加床数、设施标签（浴缸、投影、阳台、地暖）、当前房态、当前订单号。房间号是主键性质的东西，一旦定了就不要改，改号会让所有历史记录对不上。
售卖房型表的字段。房型名、售卖单位（按间夜）、含早份数、取消政策（免费取消截止到入住前多少小时）、担保方式（免担保、首晚担保、全额担保）、是否可超售、可售上限、渠道可售开关、排序权重。房型是给客人看的，所以它的字段要围绕「客人关心什么」来设计，而不是围绕「内部怎么管」。
两层之间的映射关系。一个售卖房型对应若干间物理房，一间物理房也可以属于多个售卖房型。比如 301 这间房，既可以按「大床房不含早」卖，也可以按「大床房含双早」卖，还可以按「大床房含早加景区门票」卖。三种卖法是三个房型，背后是同一间房。这是住宿业最常见的结构，也是超卖的根源——三个房型的库存如果各算各的，同一间房能卖三次。
库存表的结构。维度是「房型 + 日期」，字段是可售数、已售数、保留数、超售上限、状态。保留数是留给渠道的缓冲房量，比如总可售十间，给分销渠道保留两间，直订只能看到八间。这个缓冲的存在是为了避免渠道同步延迟导致的超卖，代价是可能空置，所以保留数要按历史占比动态调，不要一刀切。
库存扣减落在哪一层，这是关键决定。正确做法是「卖房型、锁房号」：下单时先扣房型加日期的可售数，这时还不知道具体是哪一间；入住前分配房号，分配时校验这间房在这几个日期是否被占用。把扣减落在物理房上的系统，下单阶段就要指定房号，客人还没来房号就被占死，换房、升级都变得很麻烦。
连住订单的中间日期必须全部锁住。一张五晚的订单占的不是五个房型库存，而是同一间房的五个日期。判断方法很简单：让系统试着下一张跨五天的订单，看它有没有把中间日期全部锁住。只锁首尾两天的系统，第二天一定会把中间某一晚卖出去。
三、房态流转的五个状态和三条硬规则
五个状态的准确定义。空房可用：房间干净、设施正常、可以立刻卖。已预订：有订单占着，客人还没到。在住：客人已入住。脏房：客人已退房，房间待清洁。维修：房间有设施问题，暂不可用。这五个之外还有两个「横向」的动作：锁房（带起止时间，到期自动释放）和停售（按日期关闭售卖，不分房间）。
硬规则一：在住到可用必须经过退房。系统里不提供「在住直接改可用」的选项，只能走退房流程。退房时记录退房时间、查房结果、有无消费、押金处理。这条规则挡住的是最常见的一类错误——客人还在房间，前台为了接下一单先把房态改成可用了。
硬规则二：脏房到可用必须经过清洁完成，并且记执行人。清洁完成这个动作要记三样：谁做的、什么时候做完、有没有发现遗留物品或损坏。不记执行人的系统，房间出问题时找不到人复盘，保洁之间也会互相推。
硬规则三：维修到可用必须经过维修完成，并记录维修项目。维修记录要写清楚是什么问题、换了什么件、谁修的。同一间房半年内报修三次空调，这条记录就是决策依据——该换机器了，不该再修。
三种常见的错误做法。一是把脏房当可用卖，客人推门看到上一位的毛巾；二是把维修当锁房，锁房到期自动释放，维修房被系统放出来卖了；三是用停售代替关房，停售只影响当前房型，同一间物理房关联的其他房型照样能卖出去。这三种错误都不报错，只在客人到店那一刻暴露。
锁房要带两个字段：起止时间和原因。没有原因字段的锁房，过一周就没人知道当时为什么锁。原因选项至少要有：内部留房、长包占用、待维修、渠道保留、其他。其中「待维修」这个原因应该自动转成维修状态，而不是留在锁房里等着到期释放。
四、五个高频冲突场景怎么判
场景一：一间物理房挂三个房型，被卖了两次。判断原则是「占用层只有一个来源」。所有售卖房型的可售数，都从同一份物理房占用表推导出来，任何一单成交都写进这份占用表。技术上可以做成：房型可售数 = 该房型关联的物理房数量 − 这些物理房在当日被占用的数量。这样三个房型共享同一份占用，超卖在算法层面就不可能发生。
场景二：临时维修，但晚上有已预订的客人。做法是把维修动作做成带冲突检查的：给 301 设维修时，系统先查这间房未来有没有未到店的预订，有的话弹提示，要求先换房或者先联系客人。换房要留记录：原房号、新房号、换房原因、操作人、客人是否已确认。没有这条记录，客人投诉时说「你们擅自给我换了个更差的房」，门店拿不出证据。
场景三：钟点房和过夜房混用同一间房。做法是把房态按时段切分，钟点房有独立的时段库存（比如四小时一段），结束时间之后自动回到可用，但和过夜订单不能重叠。系统判断的是「时段是否重叠」，不是「今天有没有卖过」。只按天判断的系统，白天卖了钟点房，晚上就卖不出过夜房。
场景四：加床。一间大床房可加一床，加床后能住三人。加床是订单上的附加项，不是新的房型。它不影响房型库存，但影响两件事：一是入住登记时的可住人数校验，二是保洁的工作量统计。把加床做成独立房型的系统，库存会凭空多出一间，超卖从这里开始。
场景五：房间升级和降级。客人订的是标准间，到店满房，前台给升级到套房。这个动作要记三件事：原房型、实际入住房型、差价怎么处理（免收还是补收）。升级如果只是改一下房号，房型库存不会回滚，标准间那一间的可售数就一直少着，第二天对账对不上。
判断标准可以归成一句话：每一次房态变化，都要能回答「谁、什么时候、因为什么、把哪间房从什么状态改成了什么状态」。这五个字段齐全，上面所有冲突都能事后复盘；缺任何一个，冲突就只能靠现场商量。
五、常见问题解答
一间物理房能挂几个售卖房型？
没有硬性上限，但要控制在同一间房不超过三个卖法。超过三个，客人看到一堆名字相近的房型反而不知道怎么选，前台在分配房号时也容易搞混。常见的组合是「不含早」「含单早」「含双早」，或者「标准」「可延迟退房」「含景区门票」。判断该不该加一个新卖法，看它是不是真的对应不同的客人需求，而不是为了在列表里多占一个位置。
房态能不能让前台手动改？
能改，但要限定改哪些、由谁改。空房、已预订、在住、脏房这四个之间的流转，前台可以操作，但必须走对应的动作按钮（入住、退房、清洁完成），不能直接改状态值。维修只能由工程或店长操作，因为维修涉及成本。锁房前台可以做，但要填原因。权限这样分，是为了让每一次改动都留下动作记录，而不是留一条没有来由的状态变更。
房型改名会影响历史订单吗？
会，如果房型名是直接存在订单上的。正确做法是订单存房型的内部编号，展示时再去查当前名称。这样改名之后，历史订单显示的是新名字，但内部统计口径不变。反过来，如果业务上需要保留「当时卖的是什么」，那就再存一份下单时的房型名快照，两个字段并存：一个用于统计口径，一个用于还原当时事实。
维修房要不要从可售库存里扣掉？
要，而且是自动扣。把房间设为维修，系统应该立刻把这间房从对应房型的可售数里减掉，维修完成再自动加回来。如果靠人工去改库存，一定会忘。忘一次的后果是维修房被卖出去，客人到店换房，成本远高于自动扣减带来的复杂度。
库存能不能设超售比例？
能，但只建议在一种情况下用：房源多、历史取消率稳定、有专人盯房态。超售的逻辑是靠历史取消率赌一部分订单会取消，赌对了满房率提升，赌错了要赔客人。房源少、客群以家庭和长住为主的门店，取消率低，超售基本是净损失。如果要用，超售上限必须按日期设，节假日和周末不能超。
只有七八间房，也需要这么细的房态吗？
需要，但可以简化。房间少的时候，物理房和房型可以合并成一张表，因为基本是一房一型。但五态流转和三条硬规则不能省，尤其是「脏房必须清洁完成才能回可用」这一条——房间越少，保洁和前台越是同一个人，越容易图省事跳过这一步，客人推门看到上一任的毛巾，代价和几十间房的门店是一样的。
六、九尾狐在这类问题上的做法
九尾狐在做住宿类系统时，第一件事是把「卖的东西」和「实际存在的房间」拆成两层。房型是展示层，负责给客人看、定价、做活动；物理房是占用层，负责真正的库存扣减和房态流转。两层之间用映射表连接，库存从占用层推导出来。这个结构多花一点设计功夫，但从此不会再出现「同一间房卖三次」。
第二个做法是把房态做成状态机，而不是一个可以随便选的下拉框。每个状态只暴露允许的下一步动作，动作本身带必填项：退房要填查房结果，清洁完成要填执行人，维修完成要填维修项目。前台想跳过某一步，系统不给这个选项。约束放在这里，比写在员工手册里有效得多。
第三个做法是把锁房、停售、维修拆成三个独立入口，权限也分开。锁房前台可做，停售要店长审批，维修只能工程或店长操作。三个入口各自有原因字段和到期处理逻辑：锁房到期自动释放，停售按日期自动恢复，维修必须人工确认完成。混在一个开关里，事后没人说得清这间房当时为什么不能卖。
七、综上所述
房型房态这件事，看起来是数据库设计问题，实际是现场秩序问题。两层不分，超卖就防不住；状态不锁，流程就会被跳过；三个开关混在一起，责任就落不到人头上。住宿业的毛利本来就不厚，一次旺季超卖的赔偿和差评，抵得上很长一段时间的房态维护成本。所以这部分该在系统上线前就想清楚，而不是等第一次超卖之后再回头补。