Consumer-driven Contract：前端真正依赖的是什么

Consumer-driven Contract：前端真正依赖的是什么

前端和后端都说“接口没问题”，系统却仍然可能联调失败。原因是接口文档描述了很多可能字段，但前端真正依赖的字段、错误状态和边界行为并没有被自动保护。Consumer-driven Contract，消费者驱动契约，关注的是消费者实际提出的请求和实际需要的响应。

消费者和提供者分别是谁

在 HTTP 场景中，发起请求的一方通常是消费者，返回响应的一方是提供者。消费者测试会描述一个具体交互：请求路径、参数和它需要的最小响应。提供者在自己的环境中验证，确保未来改动不会破坏这个已被使用的约定。

这和只看 OpenAPI 文档不完全一样。OpenAPI 更像一份完整规格，描述资源可能有哪些状态；消费者契约更像“真实使用案例集合”，只关心某个消费者确实依赖的行为。

AI 编程为什么需要它

AI 可以很快同时修改前端和后端，但也容易让两边各自“合理”：前端期待 userName，后端返回 name；前端把 404 当空列表，后端却返回错误对象；某个字段只是可选，前端却直接解构使用。

把消费者真实需求写成契约，AI 每次修改都要面对一组可执行的约束。它可以生成接口实现，也可以生成契约测试，但不能只根据自然语言说“应该兼容”。在拆分服务、替换后端或并行开发时，这种约束尤其有价值。

契约测试不替代功能测试

契约测试主要检查双方对消息的理解是否一致，不负责证明提供者内部业务逻辑正确，也不覆盖所有用户流程。如果契约本身写错，测试可能稳定地保护错误假设。因此，契约需要来自真实消费者和经过确认的业务场景。

一个简单的落地方式

先挑一个最容易被改坏的接口，记录前端真实发送的请求和读取的响应，再让 AI 生成消费者测试和提供者验证。以后修改接口时，先运行这组契约，再决定是否需要迁移或兼容层。

Pact 对消费者驱动契约的定义、边界和实践有完整说明，可参考官方文档。