契约测试首选go-swagger，因其支持OpenAPI双向校验确保接口定义一致；gock仅适合临时HTTP模拟，不防文档过期或语义漂移。
契约测试该用哪个库？go-swagger 还是 gock？
契约测试的核心不是“模拟得像不像”，而是“消费方与提供方是否就接口定义达成一致”。go-swagger 适合基于 OpenAPI 文档驱动的双向校验，但需要团队统一维护 swagger.yaml；gock 是纯 HTTP 模拟，轻量、快，但只管调用方视角，不防“文档过期”或“字段语义漂移”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 新项目且前后端共用 OpenAPI 规范 → 用
go-swagger+swagger generate client生成强类型 client，再配合go-swagger validate做文档一致性检查 - 已有服务、接口不稳定或只是临时验证某个下游 → 用
gock拦截http.DefaultTransport，但必须在TestMain中调用gock.Off()清理，否则并发测试会互相污染 - 别把
gock当集成测试用 —— 它不校验响应结构是否符合契约，只保证“能返回”，字段缺失或类型错不会报错
集成测试连真实数据库还是用 testcontainers？
连本地 PostgreSQL 或 MySQL 实例看似简单，但实际会导致 CI 环境不可靠：端口冲突、残留数据、版本不一致。直接写 sqlmock 又绕过了事务、索引、外键等真实行为，容易漏掉死锁或隔离级别问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用
testcontainers启一个临时容器，镜像选postgres:15-alpine（小、快），启动后执行pg_restore加载最小 schema dump，而非全量迁移 - 每个测试函数结束前必须调用
container.Terminate(ctx)，否则容器堆积导致磁盘爆满 —— 这是 CI 频繁失败最常见原因 - 不要在集成测试里写
time.Sleep(100 * time.Millisecond)等容器就绪，改用WaitForLogOutput或健康检查端点
gomock 的 EXPECT() 为什么总 panic？
panic 多半不是语法错，而是调用顺序/次数和 EXPECT() 声明不匹配。比如 mock 方法被调了 2 次，但只声明了 1 次 EXPECT().Return(...)，或者参数是 struct 但没实现 Equal() 导致匹配失败。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有
EXPECT()必须在gomock.NewController(t)创建之后、实际调用之前完成，顺序反了会 panic “controller is not in record mode” - struct 参数用
gomock.AssignableToTypeOf(...)替代具体值匹配，避免因字段顺序或零值差异失败 - 如果被测函数内部有 goroutine 异步调用 mock，必须用
ctrl.Finish()放在defer里，且测试末尾加time.Sleep确保 goroutine 执行完 —— 否则Finish()提前触发校验失败
测试覆盖率高 ≠ 集成逻辑可靠
微服务里最常漏测的是跨服务时序问题：比如 A 服务发消息到 Kafka，B 服务消费后更新 DB，再触发 C 服务回调。单测和契约测试都覆盖不到这个链路，但 go test -cover 依然可能显示 85%+。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对关键链路写 end-to-end 测试，用真实 Kafka + 本地
zookeeper容器，但只跑核心路径，不覆盖所有分支 —— 这类测试慢，放在 nightly job 而非 PR check - 在集成测试中主动制造网络分区：用
iptables在容器内丢包，验证重试逻辑是否触发、幂等 key 是否生效 - 别信日志里 “sent to kafka” 就等于消息已投递 —— 必须用
kafka-go的ReadMessage主动拉取验证，否则只是测了生产者客户端封装层
契约和集成测试真正难的不是写出来，是让它们在开发节奏里持续有效：接口一改，契约文档、mock 行为、容器初始化脚本、Kafka topic 名称，四个地方得同步动，少一个，测试就变成“绿灯幻觉”。
