前台小姑娘一句“这间房到底能不能卖”背后牵扯的是一整套酒店管理系统的房态、订单、账务和时间基准。我前后参与过几个不同规模的酒店管理系统从零搭建到上线跑通的过程有单体店也有几十家门店的连锁场景踩过的坑基本都集中在“业务规则没想清楚就急着写代码”这件事上。这篇就围绕全面综合的酒店管理系统设计与实现展开把我在实际项目里怎么拆模块、怎么定数据模型、怎么防超卖、怎么做夜审、怎么算房费这些事完整讲一遍代码和表结构都会给到可以直接参考的版本。内容适合三类人看一是刚接手酒店类项目、还分不清“房态”和“清洁状态”区别的开发二是想给自己店里搭一套轻量管理工具的经营方三是做过通用 CRUD 系统、想了解强业务型系统该怎么设计的中高级工程师。我不会只讲概念重点放在“为什么这么设计”和“实际会出什么问题”上能抄的部分尽量让你抄得动。1. 先把业务想清楚整体设计与模块拆解1.1 从一张房态图倒推系统边界我做酒店管理系统有个习惯第一版原型不画架构图先画一张房态图。因为酒店前台每天盯的就是这块屏幕——哪些房空着、哪些房住着人、哪些房脏了要打扫、哪些房被预订了还没到。这张图能跑通系统的骨架就立住了这张图跑不通后面做再多会员、报表、营销功能都是白搭。房态图上的信息其实分成两个正交的维度新手最容易把它们混成一个字段。第一个维度是占用状态空闲、已预订、在住、维修锁房。第二个维度是清洁状态干净、脏房、正在打扫、已检查。一间房可以同时是“空闲 脏房”也可以同时是“在住 脏房”。如果只用一个大枚举去表示你会发现状态组合爆炸写出来的 if-else 能绕地球一圈而且业务上根本说不清“在住脏房”到底该不该出现在可售列表里。我的处理方式是拆成两个独立字段再在查询层做组合过滤。可售房的条件是“占用状态空闲 且 清洁状态干净”而维修锁房是最高优先级任何情况下都不进可售池。这个拆分看着简单但它决定了后面预订、入住、客房管家、报表四条业务线能不能各自独立演进。客房部只关心清洁状态前台只关心占用状态两边改各自的字段互不干扰。顺着房态图往外推系统的模块边界也就出来了预订模块处理未来房态的占用核心是“预留”而不是“占用”要能取消、能担保、能 no-show。接待模块入住、换房、续住、退房核心是“把预留转成实际占用”。客房模块清洁任务、查房、维修报障核心是驱动清洁状态流转。账务模块押金、挂账、结账、冲账核心是金额的每一次变动都可追溯。夜审模块切换营业日、生成报表、处理 no-show是系统的“心脏起搏器”。报表模块出租率、平均房价、每间可售房收入口径必须统一。1.2 为什么我选择模块化单体而不是一上来就微服务这个选择我犹豫过很久。第一次做的时候热血上头直接按“预订服务、房态服务、账务服务、报表服务”拆了四个服务结果第一个月就吃到苦头入住这个动作要同时改房态、建订单、收押金跨三个服务的事务一致性靠消息补偿网络抖一下就是房态改了订单没建前台得手动修数据。单体店一天几十单出错率不高但一旦出错就是现金对不上处理成本极高。后来我改成模块化单体一个应用进程内部按包严格分层模块之间只通过明确的接口调用不允许跨模块直接查对方的表。这样做的好处很实在——入住流程放在一个本地事务里数据库保证原子性部署只需要一套进程和一个数据库小团队维护得动等到某个模块真的出现性能瓶颈通常是报表或者渠道对接再单独抽出去成本也不高。提示模块化单体的关键纪律是“包边界即服务边界”。我在项目里用架构测试工具卡住跨包的直接依赖谁违规谁改比写在文档里管用得多。模块划分上我通常按领域切成reservation预订、reception接待、housekeeping客房、folio账务、rate价格、report报表、nightaudit夜审、system权限、字典、日志八个包。每个包对外只暴露一个 Facade 接口内部实现随便改。这套结构跑了两年多加功能基本不影响老代码。1.3 营业日整个系统真正的时间基准如果只能给做酒店系统的人提一个建议我会说先把“营业日”这个概念吃透再动手写任何一行代码。这是酒店系统和普通电商系统最大的差别也是我见过最多翻车的地方。普通系统里时间是自然时间new Date()就是一切。酒店不是。酒店的账是按“营业日”算的营业日通常在凌晨某个固定时刻比如 04:00 或 06:00切换而不是 00:00。原因很现实客人凌晨两点入住这一晚的房费应该记在“昨天”的账上报表上也应该算昨天的出租率。如果按自然日切凌晨入住的订单全跑到第二天去了第二天出租率虚高第一天虚低老板看着报表能把你叫去问话。所以系统里必须有一个全局的businessDate所有涉及“哪一天的房费”“哪一天的报表”“哪一天的价格”的计算一律以它为准。营业日只能通过夜审推进不允许手工随便改也不允许用系统时间直接顶替。我在表里专门建了一张sys_business_date单行表存当前营业日所有业务代码通过一个BusinessDateHolder读取缓存加数据库双写夜审时更新。这里还有个容易忽略的细节跨营业日的在住订单。客人连住三晚房费要按每晚分别计入对应的营业日而不是一次性算在入住那天。我在账务表里给每一笔房费都打上business_date标记报表按这个字段聚合才不会出现“一晚房费算三天”的荒唐结果。2. 核心数据模型与业务规则怎么落地2.1 房型、房间、价格三条主线的表设计酒店的数据模型看着表多其实主干就三条线房型卖什么、房间具体哪间、价格卖多少钱。这三条线理不顺后面全是补丁。房型和房间是一对多但别急着在房间表里塞房型的所有属性。我的做法是房型表只放“可售属性”——房型名、床型、面积、最大入住人数、是否可加床房间表放“物理属性”——房号、楼层、朝向、房型 ID、当前房态、当前清洁状态、是否锁房。价格单独放价格日历表按“房型 日期”维度存这样调价不用动房型表节假日单独定价也方便。下面是我实际在用的核心表结构做了适当精简CREATE TABLE room_type ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL COMMENT 房型名称, bed_type TINYINT NOT NULL COMMENT 床型 1大床 2双床 3多床, max_occupancy INT NOT NULL COMMENT 最大入住人数, base_price DECIMAL(10,2) NOT NULL COMMENT 基准价单位元, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用 ) COMMENT 房型表; CREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(16) NOT NULL COMMENT 房号, room_type_id BIGINT NOT NULL, floor INT NOT NULL, occupy_status TINYINT NOT NULL DEFAULT 0 COMMENT 0空闲 1已预订 2在住 3维修锁房, clean_status TINYINT NOT NULL DEFAULT 1 COMMENT 0干净 1脏房 2打扫中 3已查, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, UNIQUE KEY uk_room_no (room_no), KEY idx_type_status (room_type_id, occupy_status) ) COMMENT 房间表; CREATE TABLE rate_calendar ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_type_id BIGINT NOT NULL, rate_date DATE NOT NULL COMMENT 对应营业日, price DECIMAL(10,2) NOT NULL, available_num INT NOT NULL COMMENT 当日可售数量, UNIQUE KEY uk_type_date (room_type_id, rate_date) ) COMMENT 价格日历;几个刻意的设计点值得说明。金额一律用DECIMAL(10,2)而不是FLOAT浮点误差在财务场景是致命的我见过对账差三分钱查了一下午的案例。日期用DATE而不是DATETIME因为价格和可售量是按“天”维度的带上时分秒只会让唯一索引失效。房间表加了version字段做乐观锁这个后面讲防超卖会用到。2.2 订单状态机别用几个布尔字段糊弄我见过最离谱的订单表用is_booked、is_checked_in、is_canceled、is_noshow四个布尔字段表示状态。结果出现“既已入住又已取消”的记录因为代码里两个字段都能被改没人拦得住。修这个 bug 花的时间比重新设计状态机还长。正确做法是单一状态字段 显式状态转移表。订单状态我定成这几个PENDING待确认、CONFIRMED已确认、CHECKED_IN在住、CHECKED_OUT已离店、CANCELED已取消、NOSHOW未到店。每个状态能转到哪些状态是白纸黑字写死的代码里用一个枚举加转移校验非法转移直接抛异常。当前状态允许的下一步触发动作PENDINGCONFIRMED / CANCELED确认预订 / 取消CONFIRMEDCHECKED_IN / CANCELED / NOSHOW办理入住 / 取消 / 夜审判未到CHECKED_INCHECKED_OUT办理退房CHECKED_OUT无终态CANCELED无终态NOSHOWCHECKED_IN客人补到店特殊情况状态机之外还有两个字段必须有order_no业务单号唯一索引和idempotent_key幂等键。订单号我不用自增 ID 直接暴露而是用“门店码 营业日 序列”生成比如S001-20240612-000137前台报单号的时候一眼能看出是哪天哪家店的。幂等键主要防渠道重复推送同一个渠道单号推两次第二次直接返回第一次的结果不会建出两个订单。2.3 账务链路押金、挂账、结账、冲账账务模块是整个系统里我最不敢偷懒的地方。酒店的钱不是“付一次”就完事一笔订单从入住到退房钱可能分好几次进来预订时收定金、入住时收押金、期间挂房账消费餐厅、洗衣、退房时统一结算、多退少补。每一笔变动都必须留痕且只能追加不能修改。我的账务模型是一个纯追加的流水表folio_entry每条记录包含所属订单、所属营业日、科目类型押金、房费、消费、退款、冲账、金额正负表示方向、支付方式、操作人、创建时间。订单的当前余额不单独存字段而是通过SUM(amount)实时算或者用一个带版本号的余额表做缓存。这样任何一笔历史都有据可查财务对账时不会出现“钱怎么少了但找不到记录”的情况。冲账是重点。前台输错金额是常态但已经入账的流水不能删也不能改只能生成一条反向流水把它冲掉。我在设计上加了个约束冲账流水的ref_entry_id必须指向原流水且原流水只能被冲一次唯一索引兜底。这条规则救过我好几次审计的时候能清楚看到“谁在什么时候冲了哪一笔、冲的原因是什么”。注意押金和房费在财务口径上是两类科目押金是负债不是收入。如果混在一起统计报表里的“营业收入”会虚高。我在科目类型里做了严格区分报表只统计收入类科目。2.4 夜审到底在做什么夜审是酒店管理系统里最像“仪式”的操作很多前台每天凌晨手动点一下。它本质上是一次系统级的日切批处理做四件事第一把当前营业日的在住订单逐条过一遍生成当天的房费流水。注意是按订单逐条生成不是一次性汇总这样每笔房费都能追溯到具体订单和房间。第二处理CONFIRMED状态但客人没到的订单按规则转成NOSHOW或者自动取消。这里要读预订时的担保类型有担保的转 NOSHOW 并扣首晚房费无担保的直接取消释放房态。第三把营业日推进一天同时刷新房态缓存、清理过期的锁房记录。第四生成日报表快照出租率、营收、平均房价落库保存。为什么要存快照因为历史数据会变——三个月后有人补录一笔账如果报表实时算历史报表就跟着变了财务会疯。存快照等于给每天的报表拍了张照片。夜审必须幂等。我见过凌晨网络断了夜审跑一半、前台又点了一次、结果房费重复生成的案例。我的做法是给夜审加一个audit_status字段未审 / 审核中 / 已审加分布式锁加每步操作的幂等键任何一步失败就整体回滚营业日不推进。宁可让前台重跑一次也不能让数据半新半旧。3. 实操过程与核心环节实现3.1 技术栈与目录结构技术选型上没有太多纠结我优先选团队熟、社区资料多、出了问题查得到的组合。后端用 Java 17 Spring Boot 3持久层 MyBatis-Plus酒店这种强 SQL 场景手写 SQL 比全自动 ORM 可控数据库 MySQL 8缓存 Redis前端 Vue 3 Element Plus报表导出用 EasyExcel。这套栈中小团队一周能搭起来招人也容易。目录结构按前面说的领域划分每个包内部再分controller / service / mapper / entity / dtocom.example.pms ├── reservation 预订 │ ├── controller │ ├── service │ ├── mapper │ └── facade 对外接口 ├── reception 接待 ├── housekeeping 客房 ├── folio 账务 ├── rate 价格 ├── report 报表 ├── nightaudit 夜审 └── system 权限/字典/日志Facade 这一层是纪律的落点。比如接待模块要查房型价格只能调rate模块的 Facade不能直接注入RateCalendarMapper。我在 CI 里加了一条架构检查规则跨包直连 mapper 直接构建失败。刚开始同事有意见觉得麻烦跑两个月之后大家都说好在改价格逻辑时心里有底。3.2 防超卖房态并发控制的三种方案对比超卖是酒店系统的头号事故。两个前台同时给同一间房办入住或者前台和渠道同时卖最后一间房只要发生一次客人到店没房住处理成本远超系统开发成本。我实际用过三种方案各有适用场景。第一种是数据库悲观锁SELECT ... FOR UPDATE锁住房记录再判断状态。实现最简单一致性最强缺点是锁粒度大、并发高时排队明显。单体店一天几十单这个方案完全够用我现在给小型项目还是首选它。第二种是乐观锁用房间表的version字段更新时带版本条件影响行数为 0 就说明被人改过重试或提示。适合读多写少的场景缺点是高并发下重试率上升前台会看到“操作失败请重试”的提示。第三种是Redis 分布式锁 库存预扣适合多渠道高并发场景。我一般按“房型 日期”维度在 Redis 里存可售数量下单时用 Lua 脚本原子扣减扣成功再落库。这个方案性能最好但引入了缓存和数据库的一致性问题需要补偿机制兜底。方案一致性吞吐实现成本适用场景悲观锁强低低单体店、小连锁乐观锁强中中中等并发Redis 预扣最终一致高高多渠道、大流量我的实际选择是乐观锁打底 房间维度串行化。核心代码长这样public void checkIn(Long roomId, Long orderId) { Room room roomMapper.selectById(roomId); if (room.getOccupyStatus() ! OCCUPY_FREE) { throw new BizException(房间当前不可入住); } int affected roomMapper.updateStatusWithVersion( roomId, OCCUPY_IN_HOUSE, room.getVersion()); if (affected 0) { throw new BizException(房态已变化请刷新后重试); } // 同一事务内创建入住单、收押金 }对应 SQL 就是一条带版本条件的更新UPDATE room SET occupy_status 2, version version 1 WHERE id #{roomId} AND version #{version} AND occupy_status 0;提示判断“能不能卖”不能只看房间状态还要看这个房型当天的可售数量。房间状态管的是“这间房”可售数量管的是“这个房型还能卖几间”两者都要校验缺一个都会出问题。3.3 房费与价格日历的计算细节房费计算看着是乘法实际坑不少。第一个坑是夜数不等于日期差。客人 6 月 10 日入住、6 月 12 日退房住的是 10 日晚和 11 日晚共 2 晚不是 2 天也不是 3 天。我的算法是从入住营业日循环到退房营业日前一天逐夜累加价格这样跨月、跨节假日都不会错。第二个坑是连住价格和单夜价格不一样。有些店做“连住三晚打折”那房费就不能简单按每天价格相加而要按连住区间匹配价格策略。我在价格日历上再加一层“价格计划”支持按连住天数阶梯定价计算时先确定适用计划再逐夜取值。第三个坑是凌晨入住。客人凌晨一点到店按营业日算还是前一晚房费也只收一晚但退房时间通常是当天中午。如果按自然日算系统会认为他住了两晚。这就是前面强调营业日的原因。房费计算的伪代码我写得尽量直白public BigDecimal calcRoomCharge(Order order) { BigDecimal total BigDecimal.ZERO; LocalDate cursor order.getCheckInBusinessDate(); LocalDate end order.getCheckOutBusinessDate(); while (cursor.isBefore(end)) { BigDecimal nightPrice rateService.getPrice( order.getRoomTypeId(), cursor, order.getRatePlanId()); total total.add(nightPrice); cursor cursor.plusDays(1); } return total; }参数选择上我把价格精度定到分四舍五入用HALF_UP并且在最终汇总时才做一次舍入中间过程不做避免多次舍入产生偏差。这个小细节在对账时能省掉很多解释。3.4 入住到退房的核心接口设计接待模块的四个核心动作——入住、换房、续住、退房——接口设计上我坚持一个原则每个动作是一个独立的原子事务不做“大而全”的万能接口。早期我图省事写过一个updateOrder接口参数里塞了七八个可选字段结果前端传错一个字段就改出脏数据排查极其痛苦。入住接口的入参我控制在最小集订单号或散客信息、房间 ID、入住人数、押金金额、支付方式。服务端做的校验包括订单状态必须是CONFIRMED、房间必须空闲且干净、房型必须匹配、入住人数不超过房型上限。全部通过后一个本地事务里完成房间状态改在住、订单状态改在住、生成押金流水、写操作日志。换房是容易出问题的地方因为它同时涉及两个房间的状态。我的处理顺序是先锁定新房并校验可入住再释放旧房两步在同一个事务里如果中途失败整体回滚不会出现“旧房放了新房没占上”的空档。换房还要处理差价——新房价格更高要补收更低要不要退这个由门店政策决定我在配置里加了个开关默认差价多退少补并且生成对应的账务流水。续住的关键是房态和可售量的双重校验。客人想多住一晚得先看这间房明天有没有被别人预订。如果被订了要么换房要么拒单。我在续住接口里先查房间未来日期的占用情况再查房型可售量两个都通过才允许续续住成功后按新营业日追加房费流水。退房接口要处理的事最多结算房账房费 挂账消费、退还押金、释放房态、把清洁状态置为脏房、触发客房打扫任务、生成结账流水。这里我特意把“释放房态”和“置脏”做成两个明确动作而不是合成一个“退房”状态因为客房部需要根据清洁状态调度合成一个状态他们就没法筛任务了。3.5 经营报表的统计口径与SQL报表是老板每天必看的东西口径错一个信任就没了。酒店最核心的三个指标是出租率、平均房价、每间可售房收入我按行业通用口径实现出租率 已售房间夜数 / 可售房间夜数 × 100%平均房价ADR 客房总收入 / 已售房间夜数每间可售房收入RevPAR 客房总收入 / 可售房间夜数注意分母是“房间夜数”不是“房间数”而且必须按营业日口径统计。举个具体例子某店 100 间房某营业日卖了 78 间客房收入 23400 元那么出租率 78%ADR 是 300 元RevPAR 是 234 元。三个数放在一起看才能判断是“降价换量”还是“提价保利润”。统计 SQL 我是基于账务流水做的因为流水带business_date和科目类型口径最干净SELECT e.business_date, COUNT(DISTINCT e.room_no) AS sold_rooms, SUM(CASE WHEN e.subject ROOM_FEE THEN e.amount ELSE 0 END) AS room_revenue FROM folio_entry e WHERE e.business_date BETWEEN #{start} AND #{end} AND e.subject IN (ROOM_FEE) GROUP BY e.business_date;可售房间夜数单独从房型可售量表按日期汇总再和上面的结果做关联计算。这里我踩过一个坑维修锁房的房间不能计入可售但它在房间表里是存在的如果直接用房间总数当分母出租率会被系统性低估。所以可售量必须用“实际可售”口径每天单独维护。报表性能上我的做法是夜审时生成每日快照表report_daily查询时直接读快照不实时算流水。历史报表永不重算除非财务明确要求重出重出也生成新版本而不是覆盖旧的。4. 常见问题与排查实录4.1 问题速查表下面这些是我和同事在联调、上线、运维阶段真实遇到过的问题按现象、原因、处理方式整理成表遇到类似情况可以先对照排查。现象常见原因处理方式同一间房出现两条在住记录入住接口并发未加锁加乐观锁或悲观锁补数据并核对账务房态显示空闲但前台说有人住缓存与数据库不一致排查缓存更新时机加版本号或短 TTL报表出租率超过 100%分母用了房间总数且未剔除锁房修正可售量口径重出报表夜审跑完房费翻倍夜审不幂等重复执行加状态字段和幂等键回滚重跑押金退了两次结账接口无幂等校验结账加订单状态校验和流水唯一约束渠道订单重复入库未做渠道单号去重建唯一索引入库前查重跨月连住房费算错按日期差算夜数改为按营业日逐夜累加退房后房间还显示在住释放房态和置脏顺序错乱事务内先释放占用再置脏补监控告警这张表里缓存不一致和幂等缺失占了绝大多数。我的经验是凡是涉及“状态”的地方先想清楚谁写、什么时候写、写失败怎么办三个问题答不上来就别写代码。4.2 几条不写在文档里的经验第一条别相信前端传来的任何状态值。我接手过一个项目订单状态是前端传上来的结果有人用工具改请求把已取消订单改回在住直接造成账务异常。状态变更必须由服务端根据动作推导前端只能传“我要做什么”不能传“我要变成什么状态”。第二条房态缓存宁可晚一点更新也不能脏。我们早期为了性能把房态全放 Redis更新时先删缓存再写库结果在并发下出现缓存被旧值回填的问题。后来改成先写库、事务提交后再删缓存并且给缓存加业务版本号读到旧版本直接穿透查库。这个改动之后房态相关的客诉基本归零。第三条金额字段永远不要在 Java 里用 double。这个不用多解释用BigDecimal且明确指定舍入模式。数据库里我曾经见过用float存房价的对账时经常差几分最后全表改成decimal才消停。第四条日志要能还原现场。酒店系统的操作日志不是给人看的是给纠纷处理用的。我把关键操作入住、换房、结账、冲账、夜审全部记成结构化日志包含操作人、订单号、变更前后值、请求 IP、时间戳。有一次客人投诉押金少退靠日志十分钟就定位到是前台操作时选错了支付方式而不是系统算错。第五条夜审时间点要可配置。不同门店的营业日切换时间不一样有的凌晨四点有的六点。我把它做成门店级配置夜审任务按配置时间触发并且允许提前手工触发比如节假日客流高峰想早点出报表。这个灵活性看着小实际用起来非常香。5. 权限、外设与后续扩展5.1 权限模型与操作审计酒店系统的权限不能只做“菜单级”必须做到按钮级和数据级。前台能办入住但不能改房价主管能改房价但不能冲账财务能冲账但不能改房态。我用的是经典的 RBAC角色绑定权限码权限码精确到接口方法接口上加注解校验。数据级权限主要按门店隔离连锁场景下一个店长只能看自己店的数据查询时强制拼门店条件这个条件由拦截器统一注入业务代码里不允许手写。审计日志单独一张表记录操作人、模块、动作、业务主键、变更内容、耗时、结果。写日志用异步队列避免拖慢主流程但涉及金额和房态的操作我要求同步落库宁可慢几十毫秒也不能丢。审计日志保留期我一般设一年超过归档到冷存储。5.2 身份证阅读器、门锁、发票机对接注意点外设对接是酒店项目里最容易被低估的工作量。身份证阅读器各家协议不同我统一封装成一个IdCardReader接口用适配器模式接不同厂商的 SDK上层业务不感知。读取失败要有明确的降级路径——允许手工录入但记录“未读卡”标记方便后续核查。门锁对接更麻烦涉及发卡、挂失、退房销卡。这里的关键是发卡失败不能让入住事务回滚。人已经住进去了卡没发出来是硬件问题不能让房态回退。我的处理是把发卡做成入住后置的异步步骤失败进入重试队列并弹窗提醒前台手动补发同时记录一条待办。发票机对接要注意金额和税率的映射以及开票失败的幂等。同一个订单重复开票是财务大忌我在开票接口上加了订单维度的唯一约束开票前先查是否已开。5.3 后续可以扩展的方向系统跑稳之后能扩展的地方不少但我建议按“业务价值 ÷ 改动成本”排序来做。渠道直连是收益最明显的把主流预订渠道的订单自动拉进来减少前台手工录入但要处理好去重和取消同步。移动端自助入住能显著降低前台压力尤其是客流高峰但要解决好身份证核验和房卡发放的硬件配合。数据分析那块我倾向于先在现有报表上加趋势和对比而不是急着上大数据平台。酒店的数据量其实不大一家店一年也就几万订单MySQL 加上合理的索引完全扛得住过早引入复杂组件反而增加维护负担。等到连锁规模上来、跨店分析需求明确再考虑抽数仓。我个人在实际操作中的体会是酒店管理系统真正的难点从来不在技术栈而在业务规则的严密程度。同一句“办理入住”背后有房态校验、价格匹配、押金收取、账务记账、外设联动五件事任何一件想漏了上线后都会以前台投诉的形式找回来。所以我现在做这类系统写代码前会先拉着前台和客房主管聊半天把他们嘴里的“应该”“一般”“特殊情况”全部记下来逐条变成状态转移和校验规则。这套方法笨但比任何架构图都管用。