t.parallel() 仅在测试隔离、无共享状态且命令行启用并行时才真正并发；加了不提速或panic的根本原因是隐式共享可变资源，如包级变量、硬编码路径等。
t.Parallel() 不是加了就快，它只在测试彼此隔离、无共享状态、且命令行启用并行调度时才真正并发执行。
为什么加了 t.Parallel() 却没提速，甚至 panic
根本原因不是并发没触发，而是多个测试偷偷共享了可变资源。Go 测试运行器只负责把标记 t.Parallel() 的测试扔进 goroutine，不帮你做任何隔离。
-
fatal error: concurrent map writes、数据库主键冲突、t.Log输出交错——这些全是竞态信号 - 典型隐式共享：包级变量（如
var db *sql.DB）、硬编码路径（"./tmp"）、log.SetOutput、未关闭的http.Server - 子测试里忘了调
t.Parallel()：父测试加了，但t.Run("case1", func(t *testing.T) { ... })里没加，逻辑仍串行 - 用了
time.Sleep()或os.Setenv()：前者让调度不可控，后者被 Go 运行时静默禁用并行
t.Parallel() 必须放在函数体第一行
位置错误会导致并行完全失效，且无任何提示或报错。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- ✅ 正确：
t.Run("valid", func(t *testing.T) { t.Parallel(); /* 实际逻辑 */ }) - ❌ 错误：把
t.Parallel()放在 setup 后、断言前，或嵌套在if分支里 - ⚠️ 注意：一旦调用
t.Parallel()，该测试就进入等待队列，直到所有非并行测试完成才开始调度
go test -p 和 t.Parallel() 是两回事
两者缺一不可，但作用域完全不同：
-
t.Parallel()是测试函数级开关：只对显式调用它的TestXxx或子测试生效 -
go test -p=4是进程级调度参数：控制「不同测试包」之间的并发数，默认为-p=4，和单包内是否并行无关 - 真实并发数 =
min(-p值, CPU 核心数, 并行测试函数数量)，不是你设多少就跑多少 - CI 推荐组合：
go test -p=2 -race，既控资源又抓竞态
表格驱动测试中循环 + t.Parallel() 的坑
这是最常翻车的场景，两个问题叠加：闭包捕获 + 并发读写共享变量。
- 必须显式拷贝循环变量：
tt := tt，否则所有子测试看到的是最后一轮值 - 不能在子测试外初始化共享资源（如
db := setupDB()），然后在并行子测试里直接用——会触发 data race - 若需复用资源（如 mock HTTP server），应在父测试中启动，并用
t.Cleanup()统一关闭；子测试内部只做无状态操作 - 启用竞态检测：
go test -race，它比日志更早暴露问题
最容易被忽略的不是“怎么写 t.Parallel()”，而是“在哪写”和“写完之后要不要跑 -race”。哪怕逻辑看起来干净，只要涉及包级变量、临时文件、mock 客户端复用，就可能在第 7 次 CI 运行时突然失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
