1. 课程导论与工程全景
1.1 什么是契约测试？
契约测试（Contract Testing）是一种介于单元测试与端到端测试之间的集成测试策略。它不直接验证整个系统的行为，而是验证两个独立服务（通常是消费者与提供者）之间的交互是否符合双方共同约定的“契约”。
核心思想： 每个服务只验证自己能否正确解析或生成符合契约的消息，而不依赖对方服务的真实部署。这避免了端到端测试的脆弱性和高昂维护成本。
契约测试通常分为两种角色：
- 消费者端（Consumer Side）： 模拟提供者返回的响应，验证消费者能否正确处理。
- 提供者端（Provider Side）： 模拟消费者发起的请求，验证提供者能否返回符合契约的响应。
| 维度 | 单元测试 | 契约测试 | 端到端测试 |
|---|---|---|---|
| 依赖环境 | 无 | 仅契约文件 | 全链路部署 |
| 执行速度 | 毫秒级 | 秒级 | 分钟级 |
| 故障定位 | 精确到函数 | 精确到接口 | 模糊 |
| 维护成本 | 低 | 中 | 高 |
1.2 什么是性能压测？
性能压测（Performance & Stress Testing）是通过模拟真实用户负载，测量系统在特定压力下的响应时间、吞吐量、资源利用率及稳定性。在 Go 项目中，压测通常借助 testing.B 基准测试框架或第三方工具（如 wrk、vegeta）完成。
性能压测的三个核心指标：
- 吞吐量（Throughput）： 单位时间内处理的请求数（RPS）。
- 延迟（Latency）： 请求从发出到收到响应的耗时，通常关注 P50、P95、P99。
- 错误率（Error Rate）： 失败请求占总请求的比例。
Go 项目特有优势： Go 的 goroutine 和 channel 模型天然适合高并发场景，但不当的 goroutine 泄漏、锁竞争或 GC 压力仍会导致性能瓶颈。压测必须与代码级 profiling（pprof）结合才能定位根因。
1.3 为什么需要闭环工程？
在传统 Go 项目中，契约测试与性能压测往往是割裂的：契约测试只在 CI 中验证接口兼容性，压测只在发布前手动执行一次。这种模式导致两个典型问题：
- 契约变更未触发压测： 修改了 API 响应结构，契约测试通过，但新字段导致序列化开销增大，压测未覆盖。
- 压测结果无法回溯到契约： 压测发现性能劣化，但无法快速定位是哪个契约变更引起的。
闭环工程 的核心思路是将契约测试与性能压测纳入同一个自动化流水线，形成“契约定义 → 契约验证 → 压测触发 → 结果反馈 → 契约调整”的循环。
1.4 Go 项目中的典型痛点与解决方案
基于对多个 Go 微服务项目的复盘，我们总结了以下四个高频痛点：
| 痛点 | 表现 | 解决方案 |
|---|---|---|
| 契约漂移 | 服务 A 修改了 API 字段，服务 B 未同步更新，上线后 500 错误 | 在 CI 中强制运行消费者驱动契约测试（CDC），契约文件作为制品管理 |
| 压测数据不可复现 | 每次压测结果差异大，无法判断是代码变更还是环境波动 | 使用 testing.B 编写可重复的基准测试，结合 -benchtime 和 -count 参数稳定结果 |
| goroutine 泄漏 | 压测时 goroutine 数持续增长，最终 OOM | 在压测前后调用 runtime.NumGoroutine() 对比，结合 pprof/goroutine 定位泄漏点 |
| JSON 序列化瓶颈 | 高并发下 encoding/json 成为 CPU 热点 |
契约测试中增加序列化性能断言，压测时对比 json.Marshal 与 jsoniter 或 protobuf 的差异 |
常见误区： 不要将契约测试与压测完全分离。契约测试通过后立即触发压测，才能尽早发现“符合契约但性能不达标”的接口。本课程后续章节将手把手实现这一闭环。
1.5 本章小结
本章明确了三个核心概念：
- 契约测试 保证服务间接口兼容性，是微服务集成的安全网。
- 性能压测 保证系统在预期负载下的响应能力，是稳定性的最后防线。
- 闭环工程 将两者串联，形成自动化反馈回路，避免“各自为政”的测试孤岛。