契约测试对「字段名/类型不变、只有业务语义变」的静默漂移是盲区：枚举值复用、单位从分改厘、时区/舍入规则变更，CI 里有没有可落地的拦截手段？

【背景】 3 年测试开发，维护一条 B 端 SaaS 的订单 + 支付链路（Java 17 + Spring Boot 3 + JUnit 5，接口自动化 pytest + httpx 约 900 条用例，共享 staging）。团队已按社区经验把断言从 assert 200 升级到了字段级契约断言（参考 id=577 与 id=1409 的分层做法），契约测试也上了 Pact 消费者驱动（参考 id=458 的落地路径）。

但过去 8 个月我复盘了 4 起线上问题，有一类共同点让我很不安：接口 schema 一个字段都没变，变的只是「同一个值代表的业务含义」，而 CI 全程全绿。具体三类：

1. 枚举值复用：refund.status=3 原来是「部分退款」，某次需求改成「全额退款」，字段名、类型、取值域都没变，只有 3 的业务含义变了。下游对账服务按旧语义处理，错账两天才被发现；
2. 单位/精度语义变：amount 字段文档一直写「单位：分」，某次需求把精度悄悄扩到厘（1 元 = 1000 分？还是 1 元 = 100 分但保留一位小数？），字段名没变，消费方按旧单位算，出 10 倍差；
3. 时区/舍入规则变：settleAt 从 UTC 改成本地时区、HALF_UP 改成 HALF_EVEN，字段名与类型都没变，对账日切边界错了。

社区里 id=458 讲「字段悄悄变了没人通知」，id=577/1409 讲断言要够强，但这三起我都没办法靠「更强断言」解决——因为断言只能验证「值长什么样」，验证不了「这个值现在代表什么」。

【现象 / 卡点】

1. Pact 契约只覆盖 schema 层（字段名/类型/必填/取值域），语义层变更对它是隐形的，消费者契约不会失败；
2. 字段级断言同理：assert status in [0,1,2,3] 在语义变更前后都成立；
3. 文档（OpenAPI/Swagger 的 description）是唯一记录语义的地方，但没人把它当「契约」管，改动不触发任何检查；
4. 这类 bug 的共同特征是只有消费方 + 业务规则一起才暴露，单侧测试天然测不到。

【已尝试的排查与结果】

• 在 OpenAPI 里给关键语义字段加 x-semantics 扩展（如 x-enum-3-meaning: "全额退款"、x-amount-unit: "分"、x-timezone: "UTC"、x-rounding: "HALF_UP"），并写了个脚本 diff 两版 OpenAPI 的扩展字段：能发现，但依赖开发主动改扩展字段，实际两次都没改，脚本白跑；
• 对 status 等关键字段做「枚举值 → 业务行为」的映射表断言（消费方按枚举值驱动行为，断言行为结果）：有效，但每加一个消费方就要维护一份映射，900 条用例里只有 40 条覆盖到了关键字段，覆盖不全；
• 让开发在 PR 描述里声明「是否改语义」：口头约定，执行率约 30%；
• 翻过 Pact 的 provider 状态管理、consumer 端 expectations，确认它们都是 schema 语义，没有「业务语义」这一层。

【期望得到的答案形态】

1. 一个明确的判断：这类「静默语义漂移」到底该不该由测试侧兜底？还是应该在架构/流程层（如语义变更必须升字段名或加版本）解决？如果有团队把「语义变更 = 破坏性变更，必须改字段名」写进了规范，想听听执行成本；
2. 如果测试侧要兜底，可落地的拦截手段：比如 OpenAPI 扩展字段 + CI diff 门禁怎么设计才能不依赖人工自觉？枚举值业务映射表怎么组织才不用每消费方维护一份？有没有「语义指纹」（对 description + 扩展字段做 hash，变更即触发消费者回归）这类做法的实例？
3. 对「枚举值复用 vs 新增枚举值 vs 拆字段」三种改法，各自的测试代价与风险对比，想听踩过的坑。

我目前的倾向是：语义变更必须伴随字段名/版本变更（把语义漂移问题「升级」成 schema 变更，让现有契约测试体系兜底），但这会让下游改动成本上升，想确认有没有团队真这么做过、代价多大。