t.Parallel()未提速的根本原因是它仅在同包内多个标记并行的测试间生效，且受-go test -p参数和CPU核心数限制；单个测试调用或存在共享状态时无效。
t.Run 本身不自动并行，必须显式调用 t.Parallel() 才能触发并发执行；且只有在多个子测试都标记并行、无共享状态、go test -p 配置合理时，才真正提速。
为什么 t.Run 里的子测试没并行起来
常见现象是加了 t.Parallel() 但 go test -v 依然串行打印、总耗时没变。根本原因不是 t.Run 失效，而是并行条件未满足：
-
t.Parallel()只对「同一包内、多个已标记并行的测试单元」生效 —— 单个子测试调用它，不会自己分裂成 goroutine - 默认
go test -p=1，强制所有测试串行；需手动设为-p=4或更高（建议 ≤ CPU 核心数） - 父测试函数里调用
t.Parallel()不会带动子测试；必须在每个t.Run的函数体第一行调用 - 子测试间若共用全局变量、临时文件、mock server 等可变资源，竞态检测会阻塞或报错，实际退化为串行
t.Parallel() 必须放在子测试函数体第一行
位置错误会导致并行失效，且无任何提示：
- ✅ 正确：
t.Run("valid", func(t *testing.T) { t.Parallel(); /* 实际逻辑 */ }) - ❌ 错误：把
t.Parallel()放在 setup 后、断言前，或嵌套在 if 分支里 —— 运行器只认第一行是否声明并行 - ⚠️ 注意：一旦调用
t.Parallel()，该子测试就进入等待队列，直到所有非并行测试完成才开始调度
循环中写 t.Run + t.Parallel 的坑
表格驱动测试最常在这里翻车，两个问题叠加：闭包捕获 + 并发读写共享变量：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须显式拷贝循环变量：
tt := tt，否则所有子测试看到的是最后一轮值 - 不能在子测试外初始化共享资源（如
db := setupDB()），然后在并行子测试里直接用 —— 会触发 data race - 若需复用资源（如 mock HTTP server），应在父测试中启动，并用
t.Cleanup()统一关闭；子测试内部只做无状态操作 - 启用竞态检测：
go test -race，它比日志更早暴露问题
go test -run 怎么精准匹配并行子测试
-run 匹配的是完整路径，和是否并行无关，但命名不当会让筛选失效：
- ✅ 安全写法：
go test -run "TestParse/valid_json"—— 前缀带父测试名，避免跨测试误匹配 - ❌ 危险写法：
go test -run "valid"—— 可能同时命中TestParse/valid和TestValidate/valid - 斜杠
/是框架解析层级的分隔符，但子测试名本身不应含/；推荐用下划线："valid_json"而非"valid/json" - 名字必须是稳定字符串，禁用
fmt.Sprintf动态生成（CI 中无法固定过滤）
真正难的不是加 t.Parallel()，而是识别哪些测试能安全并行 —— 纯计算、JSON 解析、字段校验可以；涉及文件、端口、数据库连接、全局 logger 设置的，得先隔离或 mock。别让“想快”掩盖了资源竞争的真实风险。
