go集成测试核心是隔离依赖、验证组件协作、贴近真实环境；通过接口抽象与依赖注入解耦，用testmain或testcontainers启动轻量真实依赖，分层验证模块内、跨服务及端到端子集，并规避全局状态、硬编码端口等陷阱。
Go 语言的集成测试核心在于隔离外部依赖、验证组件协作、贴近真实运行环境。它不是单元测试的放大版，也不是纯黑盒的端到端（E2E）测试，而是介于两者之间：让多个模块（如 handler + service + repo）在可控条件下一起跑，同时把数据库、HTTP 服务、消息队列等真实依赖替换成可预测、可控制的模拟实现。
用接口抽象 + 依赖注入解耦外部依赖
Go 没有泛型 mock 框架，但它的接口和组合机制天然适合测试隔离。关键不是“怎么 mock”，而是“哪里该抽象”。比如：
- 定义
type UserRepository interface { GetByID(id int) (*User, error) }，而非直接依赖*sql.DB - 在 service 层通过构造函数或方法参数接收该接口，而非在内部 new 出来
- 测试时传入一个内存 map 实现的
MockUserRepo，或使用testify/mock生成桩对象
这样，测试不启动 PostgreSQL，也能验证用户查询逻辑与业务规则是否联动正确。
用 TestMain 或 testcontainers 启动轻量级真实依赖
有些逻辑绕不开真实中间件——比如 SQL 查询优化、Redis 分布式锁、gRPC 调用序列。这时可启用真实依赖，但要轻量、隔离、自动清理：
立即学习“go语言免费学习笔记（深入）”；
- 用
TestMain在所有测试前拉起 Docker 容器（如 via testcontainers-go），创建临时 DB 实例，测试后自动销毁 - 为每个测试用例准备独立 schema 或前缀表名（如
test_users_123），避免交叉污染 - HTTP 外部服务可用
httptest.Server模拟响应，或用gomock拦截 http.Client 的 Transport
分层验证：从组件集成到流程闭环
集成测试应覆盖关键路径，而非穷举所有分支。推荐按粒度分层：
- 模块内集成：HTTP handler → service → in-memory repo，验证 API 入口到领域逻辑链路
- 跨服务集成：本服务调用另一服务的 mock gRPC client，验证协议兼容性与错误传播（如超时、非 200 响应）
-
端到端子集：启动完整服务（含真实 DB + Redis），用
http.DefaultClient发请求，校验最终状态（如订单创建后库存扣减、消息入队）
这类测试执行慢，数量宜少而精，聚焦核心业务流（下单、支付回调、定时同步），并确保有明确的 setup/teardown 清理逻辑。
避免常见陷阱
集成测试容易失控，需主动约束：
- 不用
os.Exit或全局变量修改状态；测试间必须完全独立 - 禁止硬编码端口（如
:8080），用freeport.GetFreePort()动态分配 - 不读取本地配置文件，统一用
flag.Set或结构体传参注入测试配置 - 日志和 panic 输出重定向到
bytes.Buffer，便于断言异常行为
真正可靠的集成测试，是那些能稳定运行在 CI 中、失败时能快速定位是逻辑缺陷还是环境问题的测试。
