数据契约一旦被理解成“上游不许改字段”，很快就会失效。业务一定会增加状态、调整口径、拆分字段，平台不可能靠审批把变化冻结。真正需要禁止的是未经识别、没有迁移窗口、出了问题无法回滚的变化。

我把契约看成生产者与消费者之间的变更协议。Schema 是其中可机器检查的一层，除此之外还要写清字段含义、主键、时间语义、空值、质量阈值、交付时效、owner 和弃用期限。契约的目标不是少改，而是让每次修改都有证据链。

数据平台上的 schema 变更，最危险的往往不是 ALTER TABLE 报错，而是 ALTER 成功、任务也能跑，结果却把旧字段读成了另一个含义。

按字段位置读取的系统里，删除第二列后，后面的列全部向前移动；按字段名读取的系统里，先删除 status，过一段时间又新建同名字段，旧文件中的 status 可能被误认为新字段。单看最新 DDL，两次操作都合法，历史数据的语义却已经混在一起。

Apache Iceberg 0.12.0 用永不复用的 Field ID 跟踪列。改名和重排只改变显示信息，字段身份不变；删除后再添加同名列会拿到新 ID，旧数据不会“复活”。这套规则很适合用来理解 schema evolution 的核心：兼容性不是比较两份字段名列表，而是判断字段身份、类型和值域能否连续解释。