t.Parallel()未提速甚至卡住的根本原因是测试间存在隐式共享状态，如全局变量、临时文件路径、数据库连接池等，Go测试运行器仅分发goroutine而不隔离资源。
为什么 t.Parallel() 没让测试变快甚至卡住了
根本原因不是并发没生效，而是测试间存在隐式共享状态：比如共用全局变量、临时文件路径、数据库连接池、HTTP Server 端口，或者没等异步操作结束就返回。Go 测试运行器会把标记 t.Parallel() 的测试分发到不同 goroutine，但不会帮你隔离资源。
实操建议：
- 每个测试用
t.TempDir()创建独立临时目录，别用硬编码路径如"./test_data" - 避免修改包级变量（
var db *sql.DB）；改用函数内初始化或传参注入 - HTTP 测试务必用
httptest.NewUnstartedServer+ 显式.Start()和.Close() - 有 goroutine 的测试，必须用
sync.WaitGroup或select等待完成，不能靠 sleep
哪些测试适合加 t.Parallel()，哪些绝对不能加
能并行的前提是「无依赖、无副作用、不争抢」。它不是性能银弹，而是资源调度开关。
适合加的场景：
立即学习“go语言免费学习笔记（深入）”；
- 纯计算类测试（JSON 解析、正则匹配、算法输出校验）
- 单个 HTTP handler 的输入/输出验证（用
httptest.NewRequest+httptest.NewRecorder） - mock 了所有外部依赖的单元测试（DB、Redis、第三方 API 全部 mock）
绝对不能加的场景：
- 涉及真实数据库写入/清理的测试（哪怕用了
sqlite:memory:，也需注意连接复用） - 调用
os.Setenv()或修改flag的测试（影响其他测试环境） - 使用
time.Sleep()模拟延迟的测试（时间不可控，且会拖慢整个并发组）
t.Parallel() 的作用范围和常见误用
它只对当前 *testing.T 实例生效，不影响子测试（t.Run()）——子测试默认串行，除非子测试里也显式调用 t.Parallel()。
容易踩的坑：
- 在
t.Run()外层调用t.Parallel()，但子测试里又读写同一份 map —— 并发读写 panic：fatal error: concurrent map read and map write - 子测试名重复（比如循环中用
i当名字），导致测试被覆盖或行为异常 - 误以为
t.Parallel()能解决竞态问题，其实它只会暴露竞态（Race Detector 会更容易报错）
正确写法示例：
func TestProcessItems(t *testing.T) {
t.Parallel() // 外层可并行
items := []string{"a", "b", "c"}
for _, item := range items {
item := item // 必须捕获循环变量
t.Run(item, func(t *testing.T) {
t.Parallel() // 子测试也要显式声明才并发
result := process(item)
if result != expected[item] {
t.Errorf("got %v, want %v", result, expected[item])
}
})
}
}
调试并行测试失败时的实用技巧
并行下失败不稳定？不是玄学，是状态泄露。关键不是看「哪次失败」，而是看「哪次成功掩盖了问题」。
快速定位方法：
- 先关掉并行：
go test -p 1，确认单线程下是否稳定通过 - 开启竞态检测：
go test -race，90% 的并发问题会直接报出读写冲突位置 - 用
go test -v -run=^TestName$单独跑某个测试，观察是否必现 - 在可疑位置加日志：
t.Log("start", time.Now().UnixNano())，对比多个测试的时间戳重叠情况
最常被忽略的一点：并行测试的生命周期由测试运行器统一管理，defer 在 goroutine 中可能执行时机错乱——所有清理逻辑尽量放在测试函数末尾显式调用，别依赖 defer。
