价格标准化里最贵的 bug，表面看起来完全正确。供应商返回 NetRate: 120.00，Currency: USD，平台把它重命名为 customerNetPrice 往下游传递。字段名对上了，数据类型是 decimal，流水线全绿。但没人知道这 120 美元是每晚每间房的单价、整段住宿的总价、不含佣金的净价，还是已经把税费打包在内的毛价——下游预订引擎无从分辨。

大多数集成团队都是在客诉之后才意识到问题：客户订了五晚，以为总价 120 美元，结果收到 600 美元的账单。这时候损失已经分摊到财务、客服和供应商关系经理头上。

语义侵蚀：比格式错误更隐蔽

酒店分销系统对隐式假设极不友好。A 供应商报每晚每间房的价格，B 供应商报整段住宿总价；A 把度假村费算在 headline 数字里，B 把它藏在 rateComment 里；A 用客户请求的货币响应，B 用自己默认的货币、指望平台来换算。如果把标准化当成字段映射——改个字段名、强转一下类型——这些语义差异会以静默错误的形式存活下来。

行业默认的做法是相信供应商文档，指望集成测试套件能发现不一致。但测试环境通常只用单房晚查询，恰好掩盖了「每晚单价 vs 住宿总价」的歧义。多房多晚的真实生产流量，才是问题浮出水面的地方。

HotelByte 的语义守卫机制

HotelByte 把语义完整性当作验证关卡，而不是文档约定。四阶段流水线——验证、推导、换算、缓冲应用——不只是做数据转换，而是确保每一笔金额都携带足够的上下文，可以被安全解读。

验证阶段：任何非零金额如果没有显式的 ISO 4217 货币代码，直接拒收。不从上下文推断，不回退到上一个看到的货币，不做静默默认值。这消灭了一整类 bug：供应商漏填货币，平台不会把它误解成另一种币别。

推导阶段：流水线通过互推导调和「每晚单价」和「住宿总价」两种表示。如果供应商只给总价，就用精确小数运算算出每晚单价，并把它当作一等输入对待；如果只给每晚单价，就推导出总价。下游系统同时拿到两种表示，且经过交叉校验。

换算阶段：外币兑换使用搜索时刻抓取的汇率快照，并只应用一次可配置的缓冲系数。这个快照会贯穿预订和退改流程，客户不会在结账时看到与搜索时不一致的汇率。如果换算失败，原始币种和金额会被保留并附带警告——绝不会静默丢弃。

缓冲阶段：取消截止时间按可配置的安全缓冲（默认 36 小时）提前偏移，并重新对齐到租户的业务时区。原本标记为「全额可退」的策略会按缓冲后的截止时间重新评估，客户看到的是可操作、可执行的退改状态，而不是供应商提供的过时断言。

这套机制的代价

这套流水线不是没有成本。严格的货币校验意味着某些供应商响应会被拒收，而更宽松的系统会接受它们，这会降低表面上的目录覆盖度。精确小数运算比浮点运算慢。FX 缓冲在汇率波动期会让 HotelByte 的展示价略高于供应商原始报价。36 小时的取消缓冲也缩小了客户的实际可退款窗口。

这些都是有意的取舍。平台选择正确性而非覆盖率，选择稳定语义而非裸性能，选择客户安全而非 headline 价格竞争力。在一个单次定价错误就可能吃掉一百单正确交易利润的市场里，这笔账不难算。

白皮书阅读路径

如果你想理解语义保留的具体机制，重点阅读 Price Normalization Pipeline 章节，它逐阶段给出了精确公式和失败模式。Booking Safety Lifecycle 章节也值得细读，尤其是环境隔离控制：自动测试订单标记、线上凭证仅可退款产品预订门控，以及解决模糊预订状态的两阶段超时恢复协议。Auditability 章节列出了审查者可以查询的具体指标和 trace 字段，用来验证标准化行为是否符合描述。

完整白皮书见 英文版 和 中文版。全部白皮书索引参见 Whitepaper Index。