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语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
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，而是让它们不撞在一起。
