契约测试：微服务联调最容易被跳过，也最容易在发布夜爆炸

问题：
两个服务由不同团队维护，消费方依赖提供方的某个字段和状态码。单元测试各自都过，集成测试环境不稳定经常跳过，结果提供方一次“看起来无害”的字段重命名，消费方上线后解析失败。

契约测试解决什么：
消费方定义它期望的请求和响应契约，提供方在 CI 中验证自己是否满足这些契约。契约不是完整 API 文档，只覆盖消费方实际用到的部分。提供方改字段之前，契约测试会先红，而不是等消费方线上报错。

落地方式：
消费方写契约，生成契约文件，推到契约仓库或 broker；提供方 CI 拉取契约，用 mock 或真实服务验证；双方版本用 tag 关联，提供方发布前必须通过所有消费方契约。工具上 Pact 是比较成熟的选择，但核心不是工具，是“消费方定义、提供方验证”这个方向。

常见误区：
第一，把契约测试写成提供方的集成测试，失去消费方视角。第二，契约覆盖所有字段，维护成本爆炸，应该只覆盖实际依赖。第三，契约通过就认为兼容，忽略了语义变化，比如状态码没变但含义变了。第四，没有版本管理，提供方不知道要兼容哪些消费方版本。

判断信号：
如果团队经常在发布前临时拉群联调、靠人工点页面确认兼容性，契约测试的收益就很明显。它不是替代集成测试，是把“兼容性”从发布夜的偶然发现，变成 CI 里的确定性检查。成本主要在前期梳理消费方依赖，之后每次发布都在还利息