Pact 是消费者驱动的契约测试工具，解决 C# 微服务中 Provider 接口变更导致 Consumer 反序列化失败、状态码不匹配等运行时错误，通过生成并验证 JSON 契约保障 API 协议一致性。
什么是 Pact 契约测试，它在 C# 里解决什么问题
Pact 是一种消费者驱动的契约测试（Consumer-Driven Contract Testing）工具，核心目标不是测接口功能是否正确，而是确保服务提供方（Provider）的 API 响应结构、状态码、字段类型、必选字段等，始终满足消费者（Consumer）代码中实际依赖的约定。C# 中用 Pact 主要防止“改了 Provider 接口但 Consumer 没同步更新”导致的运行时崩溃，比如 NullReferenceException 或反序列化失败。
常见错误现象包括：
- Consumer 升级后调用 Provider 报
JsonSerializationException（字段名变了、类型不匹配） - Provider 新增了非空字段，但 Consumer 的 DTO 没加对应属性，反序列化失败
- Provider 改了 HTTP 状态码（如 200 → 201），Consumer 的
EnsureSuccessStatusCode()报错
它不替代集成测试，也不验证业务逻辑；它是介于单元测试和端到端测试之间的一层“协议守门员”。
C# 中用 Pact.NET 写消费者测试的关键步骤
Pact 在 C# 生态主要靠 PactNet 库（支持 .NET Core 3.1+ 和 .NET 5+）。消费者测试本质是“模拟 Provider”，记录 Consumer 发出的请求与期望响应，生成一个 JSON 格式的契约文件（consumer-name-provider-name.json）。
实操要点：
- 安装 NuGet 包：
PactNet和PactNet.Windows（Windows）或PactNet.Linux（Linux/macOS） - 测试中不要直接调用真实 HTTP 接口，而是用
PactBuilder构建 Mock Server，把 Consumer 的 HTTP Client 指向它（例如通过HttpClient的BaseAddress） - 每个测试用例只描述一个交互（Interaction），必须显式调用
UponReceiving(...).WithRequest(...).WillRespondWith(...) - 测试末尾必须调用
VerifyInteractions()，否则契约不会写入磁盘 - 生成的契约文件默认放在
pacts/目录下，需提交进 Git，供 Provider 端验证使用
示例片段（简化）：
var config = new PactConfig { SpecificationVersion = "4.0" };
using var pact = new PactBuilder(config)
.ServiceConsumer("OrderClient")
.HasPactWith("OrderService");
<p>pact
.UponReceiving("a request to get order by id")
.WithRequest(HttpMethod.Get, "/api/orders/123")
.WillRespondWith(200)
.WithHeader("Content-Type", "application/json")
.WithJsonBody(new {
id = 123,
status = "confirmed",
total = 99.99m
});</p><p>await pact.VerifyAsync(async ctx => {
var client = new HttpClient { BaseAddress = ctx.MockServerUri };
var resp = await client.GetAsync("/api/orders/123");
// ... 反序列化并断言业务逻辑
});Provider 端如何用 Pact 验证 API 是否符合契约
Provider 测试不是重写接口逻辑，而是加载消费者生成的契约文件，启动真实 Provider 服务（或其测试实例），让 Pact 发起预定义请求，并校验响应是否匹配。
关键注意事项：
- Provider 测试需能启动被测服务（通常用
WebApplicationFactory<t></t>或TestServer） - 使用
PactVerifier加载本地pacts/下的 JSON 文件，指定 Provider 的 Base URL（如<a href="https://www.php.cn/link/6060d322713797e84f598ea25c812cab">https://www.php.cn/link/6060d322713797e84f598ea25c812cab</a>） - 必须配置
WithProviderStateHandler—— 因为契约中可能包含 Provider State（如 “an order exists”），你需要在这里准备测试数据（比如插入测试订单到内存 DB） - 不支持自动路由匹配：如果契约里是
GET /api/orders/123，而你的 Controller 是[Route("orders/{id}")]，Pact 会因路径不完全一致而失败，建议契约路径与实际路由严格对齐 - 验证失败时，错误信息会明确指出哪条字段类型不符、哪个 header 缺失，但不会告诉你“Consumer 为什么这么写”——所以契约文件必须附带清晰的交互描述
容易被忽略的兼容性陷阱和工程实践
契约测试不是设好就一劳永逸，C# 微服务场景下几个高频坑：
-
Newtonsoft.Json和System.Text.Json行为差异会导致契约生成/验证不一致（比如 null 处理、日期格式、驼峰命名），Provider 和 Consumer 必须统一序列化器配置，或在 Pact 配置中显式指定JsonSerializerSettings - DTO 类用了
[JsonProperty("xxx")]或[JsonPropertyName("xxx")]，但契约里字段名是 PascalCase，而 Provider 返回的是 camelCase —— Pact 默认不做转换，需在消费者测试中用WithJsonBody显式写出期望字段名 - 多个 Consumer 对同一 Provider 接口有不同期望（比如 A 要字段
discountAmount，B 不需要），Pact 会合并所有契约，Provider 必须满足全部；这时要么拆分接口，要么用 Provider State 控制字段返回逻辑 - Pact 文件没纳入 CI：Consumer 提交新契约后，Provider 的 CI 没拉取最新 pact 并运行
Verify，等于契约形同虚设
真正起作用的节点，永远是 Provider 端验证通过且结果回传给 Consumer 的那一刻——不是写完测试，而是验证失败时有人立刻去修。
