testify 仅增强 go testing 包的断言与模拟能力，不提供微服务集成测试所需的服务启动、依赖管理、异步等待或生命周期控制；集成测试需真实调用 http/grpc、连接数据库/消息队列，并手动处理端口分配、资源清理与超时控制。
Testify 本身不提供微服务集成测试能力，它只是增强 Go 原生 testing 包的断言和模拟支持；真正做集成测试，得靠你启动真实服务、构造 HTTP/gRPC 调用、管理依赖（如数据库、Redis），Testify 只负责让断言更清晰、失败信息更可读。
为什么不能只靠 assert 或 require 做微服务集成测试
集成测试的关键是验证多个组件协同工作的行为——比如 HTTP handler 是否正确调用下游 service、是否持久化到 PostgreSQL、是否发了 Kafka 消息。Testify 的 assert.Equal 或 require.NoError 只能校验单次调用结果，无法覆盖网络延迟、超时、重试、事务边界等真实场景。
-
assert在失败时继续执行，可能掩盖后续依赖错误；require会终止当前测试函数，但不会帮你清理已启动的端口或 DB 连接 - 微服务间常有异步通信（如消息队列），
assert无法等待事件发生，需配合time.Sleep或 channel 同步，而 Testify 不提供等待工具 - Testify 没有内建的 mock server（如 WireMock）、DB fixture 加载、或服务生命周期管理——这些都得你自己写或引入其他库（如
testcontainers-go）
必须手动启动服务并控制生命周期
Go 微服务集成测试里，最常见错误是直接复用 main() 启动逻辑，导致端口冲突、全局状态污染、或测试间相互干扰。正确做法是把服务启动封装成可配置、可关闭的函数。
- 用
net/http/httptest测试 HTTP handler 是轻量级单元测试，不是集成测试；集成测试应走真实端口（如localhost:8081） - 启动前检查端口是否空闲：可用
net.Listen("tcp", ":0")获取随机空闲端口，再传给服务配置 - 务必在
defer func() { srv.Shutdown(ctx) }()中关闭服务，否则多次运行测试会报address already in use - 避免在
init()或包级变量中初始化 DB 连接池，应在每个测试函数内新建 client 并显式关闭
用 testify/mock 替代真实依赖时的典型陷阱
Testify 提供 mock 包，但它只是基础桩（stub）框架，不支持自动记录调用顺序、不处理并发调用、也不生成 mock 实现——你需要手写 MockXxxService 结构体并实现接口。
- 别在集成测试里 mock 数据库或消息中间件：这退化为单元测试；集成测试要测“真实连接 + SQL 执行 + 索引生效”
- 如果 mock 外部 API（如支付网关），确保 mock server 返回与生产一致的 HTTP 状态码、headers 和 body 字段，否则
assert.JSONEq会因字段顺序或空格失败 -
mock.On("Send", mock.Anything).Return(nil)中的mock.Anything无法校验参数结构；要用mock.MatchedBy(func(v interface{}) bool { ... })显式检查入参 - 记得调用
mock.AssertExpectations(t)，否则即使没调用预期方法，测试也会通过
HTTP 集成测试中 assert 和 require 的实际用法
对 HTTP 响应做断言时，别只看 status code；微服务响应常含 trace-id、retry-after、content-encoding 等关键头，且 JSON body 字段顺序不可靠。
- 用
require.Equal(t, http.StatusOK, resp.StatusCode)检查状态，而非assert——状态错就无需继续解析 body - body 解析后优先用
assert.JSONEq比较，它忽略字段顺序和空白符；assert.Equal直接比字符串会因换行/缩进失败 - 检查 header 用
assert.Contains(t, resp.Header.Get("Content-Type"), "application/json")，避免硬编码完整值（如application/json; charset=utf-8） - 超时控制必须设在 client 层：
http.Client{Timeout: 5 * time.Second}，而不是靠time.Sleep+assert等待
真正难的不是写断言，而是让每次测试都干净启动、准确等待、可靠清理——Testify 只帮你把“期望 vs 实际”的差异说清楚，剩下的事，得你亲手拿 os/exec、testcontainers-go、或自研的 test helper 来填。
