一句话定义：契约测试（Contract Testing）是把「调用方需要什么、提供方承诺给什么」写成一份可自动验证的约定（contract），让两端在各自的流水线里独立校验，从而在不用把整套系统拼起来的前提下，确认双方还接得上。
为什么需要它
微服务和前后端分离之后，A 服务要调 B 服务。传统做法是搭一套完整环境跑端到端测试（End-to-End Testing），把链路从头点到尾。问题是慢、脆、还经常因为无关的环境问题挂掉，一个改动的反馈要等半小时。
契约测试换了思路：不去拼系统，只去核对约定。消费者（consumer）端写测试，把「我发这样的请求，期望收到这样的响应」记录下来，生成一份契约文件；提供方（provider）拿到这份契约，在自己的测试里回放这些请求，检查真实响应是否仍然匹配。字段被改名、被删掉、类型从数字变成字符串、状态码变了——任意一边的流水线立刻变红，而这时候一行代码都还没上线。
打个比方
两家工厂合作做插头和插座。端到端测试相当于把两台电器搬到同一个房间插上试；契约测试相当于双方各自量好插头的规格：几根针、多粗、间距多少。插座面板换成什么颜色都无所谓，只要针距没变就还能插。契约就是那份写死了针距的图纸。
和相邻概念的边界
| 测试类型 | 关注什么 | 跑在哪 | 速度与稳定性 |
|---|---|---|---|
| 单元测试 | 单个函数内部逻辑 | 本机 | 最快、最稳 |
| 集成测试 | 自己代码 + 真实依赖（数据库、消息队列） | 带依赖的环境 | 中等 |
| 契约测试 | 两个服务之间的接口约定 | 双方各自的 CI | 快、稳定 |
| 端到端测试 | 整个系统的业务结果 | 完整环境 | 慢、容易碎 |
要点是：契约测试不验证业务逻辑对不对，只验证「能不能对上」。它不能取代端到端测试，而是把接口层的回归问题挡在前面，让端到端只保留少量关键路径。
它还常和「消费者驱动」（consumer-driven）一起出现——由调用方提出需求，而不是提供方自己写文档，因为提供方往往并不知道自己被怎么用。
对从业者和普通人的意义
工程上，接口变更不再靠「我改完了，群里喊一声」。契约文件进代码库、进 CI，谁破坏约定谁的流水线红，影响面评估变成了自动化的。
放到 AI 应用里也一样：模型调工具时的参数结构（schema）、自家 API 的返回格式，一旦被多个上游依赖，都值得用契约测试锁住。
对非技术同学，可以把它理解成合同：与其等出了事故再对质，不如一开始就把条款写成可执行的检查，双方各自照着自己那份核对。具体工具和写法各家不同，选型以官方文档为准。