t.Parallel()未提速的根本原因是它仅在同包内多个标记并行的测试间生效，且受-go test -p参数和CPU核心数限制；单个测试调用或存在共享状态时无效。
t.Parallel() 为什么没让测试变快？
根本原因：t.Parallel() 不是“开 goroutine 就完事”，它只对**同一包内、标记为并行的测试函数之间**生效，且受 go test -p（并行度）和 CPU 核心数共同限制。如果你只写了一个 t.Parallel()，或者测试里混着大量串行操作（比如共用全局状态、未隔离文件/端口），那它基本等于没开。
- 常见错误现象：
go test -v看到所有测试按顺序打印，时间也没缩短 - 真正生效前提：至少两个及以上测试函数都调用了
t.Parallel()，且彼此无阻塞依赖 - 注意：子测试（
t.Run()）里调用t.Parallel()才算独立并行单元；顶层测试函数调用只影响它自己，不带动子测试 - 性能影响：默认
-p=1时，t.Parallel()完全无效；建议显式加go test -p=4或根据 CPU 数调整
哪些测试适合加 t.Parallel()？
适合加的前提是：测试逻辑彼此独立、不共享可变状态、不竞争外部资源。典型场景包括纯计算、JSON 解析验证、mock 后的业务逻辑断言等。
- 推荐场景：
TestParseConfig、TestValidateInput、TestCalculateScore这类无副作用的单元测试 - 禁止场景：涉及文件读写（
os.Open）、启动本地 HTTP server（http.ListenAndServe）、操作数据库连接池、修改全局变量（如log.SetOutput）的测试 - 参数差异：不需要改函数签名或测试结构，只要在函数体开头加一行
t.Parallel()即可启用 - 兼容性：Go 1.7+ 全支持，但老版本（如 1.6）会忽略该调用，不报错也不生效
怎么避免 t.Parallel() 引发数据竞争？
并行测试本质是多个 goroutine 并发执行，一旦共用变量（尤其是包级变量、全局 map、未 sync.Once 初始化的单例），就会触发 go test -race 报告 data race。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见错误现象：
fatal error: concurrent map writes或WARNING: DATA RACE日志 - 关键原则：每个测试函数必须完全自包含——用局部变量、临时文件（
t.TempDir()）、独立 mock 对象 - 避坑示例：不要在测试前初始化
var db *sql.DB全局变量；改用setupDB(t)函数每次新建连接 - 路径注意：
t.TempDir()返回的路径天然隔离，比手动拼/tmp/test-123更安全
并行测试的调试和可观测性怎么做？
并行下日志交错、失败定位难，不能靠 print 调试，得靠 Go 测试框架原生能力。
立即学习“go语言免费学习笔记（深入）”；
- 错误信息识别：失败时
t.Error()输出会带明确测试名（如TestFoo/TestBar），但需确保子测试命名清晰 - 调试技巧：临时注释掉其他并行测试，或加
if !t.Run("sub", func(t *testing.T) { ... }) { return }拆解 - 性能验证：用
go test -bench=. -benchmem -run=^$配合-cpu参数看吞吐变化，比单纯看go test -v时间更准 - 容易被忽略的一点：
t.Parallel()不改变测试超时逻辑——单个测试仍受-timeout限制，不是“总时间缩短”，而是“多个测试重叠执行”
