【背景】 我做了 8 年技术文档与指标体系，最大的体感是：schema 层面的变更（字段名 / 类型 / 枚举）大家已经会管了——契约测试、Schema Registry、Avro 演进规则，工具链是齐的。但真正让业务拍桌子的，永远是那一类「字段都没变，语义悄悄变了」的静默漂移：
- 金额单位从「分」改成「厘」，字段名、类型、枚举全都没动；
- 时区从 UTC 悄悄改成「业务本地时区」，但字段还叫
created_at； - 枚举值复用：老值
status=3原来是「已取消」，新版本拿来当「风控冻结」； - 舍入规则从「四舍五入到分」改成「截断到厘」，字段精度没变。
这类变更契约测试一律放行，因为「契约没破」；但下游 80+ 个指标的计算口径瞬间全错，而且往往要等业务方对账对不上才被发现——滞后 1~3 周。站内 1415 的提问（schema 变更导致 3 个核心指标口径漂移 8%）和 2398 的提问（契约测试对语义漂移是盲区）本质上都是这个问题，但我想把它从「测试工具能不能拦」抬升到「流程该由谁负责」来谈。
【常见的两种（甚至三种）做法】 方案 A：工程侧 schema 版本化 + 双跑。把口径当作 schema 的一部分，给「金额单位」「时区」「舍入规则」这类语义属性也做版本，变更走「老口径 + 新口径」双跑 N 天，比对 diff 再切流。
- 优点：拦截发生在 CI / 发布环节，是「机器守门」。
- 缺点：双跑成本不低（存储 ×2、计算 ×2、对账脚本要写），且很多团队根本没「口径注册表」可双跑；语义属性散落在业务代码里，工程侧未必知道哪些字段是「指标字段」。
方案 B：数据侧口径冻结 + 变更评审。数据团队维护一份「口径注册表」（指标 → 依赖字段 → 业务语义），任何字段语义变更必须走数据侧评审，登记影响面（哪些指标受影响、哪些报表要回刷）。
- 优点：从「业务语义」视角守门，天然覆盖契约测试的盲区；评审时能拿到「这个字段被 12 个指标引用」的影响面数据。
- 缺点：靠「人守门」，依赖流程执行力和评审 SLA；如果数据团队和业务团队不同步，评审可能形同虚设；而且数据团队未必有权限拦住工程侧的发布。
方案 C：两者混合。核心指标走 B（评审 + 注册表），同时工程侧在 CI 里加一个「指标字段语义变更」的轻量 lint（比如检测金额字段注释 / 单位标注的变化），作为兜底。
【我的倾向与理由】 我倾向 C，但权重明显偏向 B。理由有三：
- 守门员的本质是「谁最懂业务语义」。工程侧擅长「结构有没有变」，但「分变厘」在工程侧看来只是注释改了一个字——只有数据 / 业务侧才知道这是口径变更。把守门责任放在不懂语义的一方，等于把钥匙交给了锁不匹配的人。
- 双跑成本被低估了。我做过一次核心指标双跑，光是「新老口径对齐时间窗口」就花了 2 周，因为两边的小时边界处理不一致（一个是自然日，一个是滚动 24h）。双跑解决的是「变更后的正确性验证」，不是「变更前的拦截」——它更适合作为 B 的兜底，而不是 B 的替代。
- 可落地性。口径注册表可以很轻：一张表（指标名 / 依赖字段 / 业务语义 / 单位 / 时区 / 舍入规则 / 负责人），变更时查这张表就能拿到影响面。CI lint 可以很轻：只检测「指标字段」的注释 / 单位标注变化，触发通知，不阻塞发布。两个轻方案加起来，落地成本远低于全量双跑。
但我承认 C 有一个硬伤：它依赖「口径注册表」的完整性。如果注册表只登记了 30% 的指标，那 B 的守门就是漏的。所以真正的争点可能是：口径注册表的「覆盖率」怎么保证？是强制登记（不登记就不能上报表），还是事后补全（先跑起来再登记）？ 这两个选择背后是「流程严格度 vs 团队接受度」的取舍，我没有标准答案。
【想听大家怎么选】
- 你们团队的核心指标有多少个？口径注册表覆盖了多少？是强制登记还是事后补全？
- 你们遇到「语义漂移」时，第一次发现是 CI 拦下来的，还是业务方对账对不上才发现？滞后多久？
- 你们的双跑是怎么做的？对齐时间窗口的坑是怎么填的？
- 如果让你从 0 开始搭，你会先做 A（双跑）还是 B（评审）？为什么？
- 有没有「口径注册表」被团队当成「额外负担」而绕过去的真实案例？怎么破的？
引用：站内 1415（指标口径漂移 8% 的现场）、2398（契约测试对语义漂移是盲区的讨论），这两个提问是本次话题的直接触发点。