解析Golang中的测试并行度控制 Go语言GOMAXPROCS对并发测试的影响

go测试默认串行执行testxxx函数；同一包内需显式调用t.parallel()才能并行，-p仅控制测试包级并发，gomaxprocs影响goroutine调度而非测试并行性。

Go 测试默认是串行执行的，go test 不会自动并行跑多个 TestXxx 函数

很多人误以为加了 -p 或设了 GOMAXPROCS 就能让不同测试函数并发跑，其实不是。Go 的测试框架默认把每个 TestXxx 当作独立单元，彼此串行执行——哪怕你开了 100 个 goroutine 在单个测试里，也只影响该测试内部。

真正控制「多个测试函数之间是否并行」的是 -p 参数（或 GO111MODULE=on go test -p=N），它限制的是同时运行的测试包数量，对同一包内的多个 TestXxx 无效。

• 想让同一包里的多个测试函数并行？得显式调用 t.Parallel()
• 没调 t.Parallel() 的测试，永远排在所有并行测试之后执行
• 同一包中混用并行/非并行测试时，Go 会等所有并行测试结束才启动非并行的，这点容易导致耗时误判

GOMAXPROCS 影响的是 goroutine 调度粒度，和测试并行性无直接关系

GOMAXPROCS 控制的是可同时执行 OS 线程数（即 P 的数量），它决定「一个 Go 程序最多能有多少个 goroutine 真正并行执行」，但不决定「哪些测试能一起跑」。

比如你在 TestA 里启动了 50 个 goroutine，GOMAXPROCS=2 意味着最多 2 个能真正在 CPU 上并行，其余在等待；但如果你有 TestA 和 TestB 都调了 t.Parallel()，它们能否同时跑，取决于 go test -p 和测试包结构，跟 GOMAXPROCS 无关。

立即学习“go语言免费学习笔记（深入）”；

• GOMAXPROCS=1 下，t.Parallel() 仍有效：只是所有并行测试的 goroutine 共享一个 P，调度仍是并发而非并行
• 本地开发时设 GOMAXPROCS=1 可复现竞态问题，但别误以为它“禁用了并行测试”
• CI 环境中若 GOMAXPROCS 被意外覆盖（比如被其他工具注入），可能让本该暴露的 race 变得不明显

用 t.Parallel() 前必须确认测试间无共享状态

这是最常踩的坑：加了 t.Parallel() 却没清理全局变量、临时文件、数据库连接、http server 端口等，导致测试间干扰甚至随机失败。

典型现象包括：单测通过，加上 t.Parallel() 后 panic、超时、断言失败；或者只在 CI 上偶发失败。

• 避免修改包级变量：var counter int 在并行测试里会被多个 TestXxx 同时读写
• 临时目录要用 t.TempDir()，别硬写 /tmp/test-xxx
• 启动 HTTP server 时端口要动态分配（如 http.ListenAndServe(":0", nil)），再从 listener.Addr() 提取真实端口
• 数据库测试建议每测试用独立 schema 或加随机后缀，不要共用 test_db

性能差异主要来自资源争抢，不是 CPU 核心数本身

开启并行测试后变慢，往往不是因为 CPU 不够，而是磁盘 I/O、内存带宽、锁竞争或外部服务限流造成的。

例如：10 个并行测试都往同一个 sqlite 文件写数据，会因文件锁排队；或都调用本地 mock HTTP server，而那个 server 内部用了单例 mutex，就成了瓶颈。

• 观察 go test -v -race 输出，看是否有 goroutine 长时间阻塞在锁或 channel 上
• 用 go tool trace 查看实际 goroutine 调度情况，比看 CPU 使用率更有用
• 对 I/O 密集型测试，并行未必加速，有时串行反而更稳（尤其涉及文件系统或网络）

并行测试的边界很薄：它只保证调度自由，不保证资源自由。真正难的从来不是开几个 goroutine，而是让它们不撞在一起。