并发测试中 goroutine 泄漏的典型表现是进程不退出、cpu 空转、pprof 显示大量阻塞在 select{} 或 time.sleep 的 goroutine，主因是未用 context 控制生命周期或未显式关闭外部依赖。
并发测试中 goroutine 泄漏的典型表现
跑完集成测试后进程不退出、CPU 持续空转、pprof 显示大量阻塞在 select{} 或 time.Sleep 的 goroutine——这基本是调度器没正确回收导致的。根本原因不是并发度高，而是测试用例里启了 goroutine 却没配对的取消或超时控制。
- 所有长期运行的 goroutine 必须绑定
context.Context，且测试主函数要传入带 timeout 的context.WithTimeout - 避免在
testHelper()里直接用go func(){}()；改用g.Go(func() error { ... })配合errgroup.Group - HTTP 客户端、数据库连接、消息队列消费者等外部依赖，必须显式调用
Close()或Shutdown()，不能只靠 defer
用 testify/suite + sync.WaitGroup 控制测试生命周期
原生 testing.T 不支持跨用例共享状态，但大规模集成测试常需复用 DB 连接池、mock server 等资源。硬写 init() 或全局变量会污染并行执行，正确做法是把资源生命周期和测试套件绑定。
- 定义结构体实现
testify/suite.Suite，在SetupSuite()里启动共享服务（如httptest.NewUnstartedServer），用sync.WaitGroup等待就绪 -
TearDownSuite()中先关闭监听，再wg.Wait()确保所有 handler goroutine 退出，最后关 DB 连接池 - 每个测试方法内禁止重置全局
http.DefaultClient，应通过字段注入定制 client：s.Client = &http.Client{Timeout: 3 * time.Second}
testing.T.Parallel() 的适用边界与陷阱
不是所有集成测试都适合加 Parallel()。它只保证本测试函数与其他 Parallel() 测试并发执行，但不解决资源竞争——比如多个测试共用同一个 PostgreSQL schema，就会因 DDL 冲突而随机失败。
- 仅对「读多写少」且资源隔离的场景启用：例如并发调用不同微服务 endpoint、查不同 tenant 的缓存
- 写操作（INSERT/UPDATE/DROP）必须串行，或改用临时命名空间：PostgreSQL 用
CREATE SCHEMA test_123，Redis 用不同 db index - 注意
go test -p=4控制的是包级并发数，和t.Parallel()是两层机制；混用时实际 goroutine 数 = p × Parallel 测试数，容易打爆 DB 连接池
调度策略：按依赖拓扑分组而非简单轮询
盲目提高并发数只会让慢接口拖垮整体吞吐。真实服务间有强依赖（如订单服务依赖用户服务），应该按调用链路分层调度，而不是把所有测试用例扔进一个 chan 轮着跑。
立即学习“go语言免费学习笔记（深入）”；
- 用 DAG 描述服务依赖，生成执行序：用户服务就绪 → 订单服务启动 → 支付服务启动，每层内部可并发
- 给每个测试标记
// +build integration_user，用go test -tags=integration_user分批执行，比 runtime 分流更稳定 - 监控关键路径耗时，当某服务响应 P95 > 2s 时，自动降级该层并发度：从
concurrency=10动态切到concurrency=3
真正难的不是起多少 goroutine，而是让它们在依赖就绪时才启动、在资源不足时主动退让、在失败时不卡死整个调度器——这些细节藏在 context 取消路径、error group 的传播逻辑、以及每个 Close() 调用的位置里。
