一句话定义：数据契约（Data Contract）是数据生产方（上游）和消费方（下游）之间签的一份机器可读的约定，写清楚"我给你的数据长什么样、什么时候到、坏了谁负责"。
为什么需要它
设想你开餐厅，和菜贩口头说好每天送五花肉。某天他开始送后腿肉，你没发现，照常做菜——客人不投诉，只是慢慢不来了。数据管道就是这样：上游把 user_id 从整数改成字符串，或者把时间戳从 UTC 改成北京时间，下游不会报错，只会静默地把垃圾喂给模型。训练时特征均值是 3.2，上线后变成 320，模型照样输出，只是准确率悄悄掉了。
数据契约就是把口头约定变成合同：字段名、类型、是否可空、单位、枚举值、主键唯一性，还有最容易被忽略的新鲜度——这张表每小时更新还是每天更新，最长延迟多久算违约。
它和相邻概念的区别
| 概念 | 管什么 | 谁负责 |
|---|---|---|
| Schema（模式） | 只描述结构：字段名和类型 | 通常只是文档 |
| 数据质量检查 | 事后发现坏数据 | 消费方自己兜底 |
| SLA（服务等级协议） | 服务可用性、响应时间 | 平台/服务方 |
| 数据契约 | 结构 + 语义 + 新鲜度 + 变更流程 | 上下游共同签署 |
关键差别在于：schema 是描述，契约是断言。它会被写进代码仓库，在 CI 里跑校验，不满足就构建失败；破坏性变更（删字段、改类型、改枚举含义）必须走评审、升版本、提前通知下游。所以契约约等于"schema + 数据层面的 SLA + 变更管理"。
对从业者的实际意义
做特征工程和训练管道的人最该关心：训练用的特征定义和推理时的特征定义是不是同一个。同一个名字在两张表里含义不同，是模型线上效果崩掉最常见的原因之一，而且几乎不会有报错。
落地时可以从三处着手：一是把契约文件和生产数据的代码放在同一个仓库，改数据必须先改契约；二是把新鲜度做成监控告警，表超过约定时间没更新就叫醒人；三是行数、空值率、枚举范围这类统计量设阈值，波动过大自动拦截。
也要承认边界：探索性分析阶段过早加严格约束会拖慢迭代，契约更适合已经进入稳定生产的关键数据集。另外各家工具的契约描述格式并不统一，具体字段写法以官方文档为准。
一句话收尾：数据契约不能让你拿到更好的数据，但能让你在数据变坏的那一刻就知道。