t.parallel()未提速的根本原因是它仅在同包内多个显式调用该方法的测试间生效，且受-go test -p参数和cpu核心数限制；单个调用、共享状态或位置错误均导致并行失效。
加了 t.Parallel() 但测试没变快，甚至 panic 或随机失败——不是函数写错了，而是并行条件根本没满足，或者资源没隔离。
为什么 t.Parallel() 没触发并发执行
它只在「同一包内、多个测试函数（或子测试）都显式调用 t.Parallel()」时才可能并发；单个测试调了，等于白加。
- 默认
go test -p=1，强制所有测试串行；必须显式指定-p=4或更高（建议 ≤ CPU 核心数） -
t.Parallel()必须放在函数体第一行，早于t.Log、t.Run、任何 setup 逻辑；放错位置会被静默忽略 - 父测试调了
t.Parallel()，不会让里面的t.Run()自动并行；每个子测试内部也得自己调一次 - 如果包里只有 1 个测试函数调用了
t.Parallel()，其余都是串行，那它仍得等所有串行测试跑完才开始调度
表格驱动测试中 t.Run + t.Parallel 的典型翻车点
循环变量捕获 + 共享状态 = 随机失败的根源。这不是 Go 的 bug，是闭包和并发共同暴露的逻辑漏洞。
- 必须写
tc := tc拷贝循环变量，否则所有子测试看到的是最后一轮值 - 不能在
t.Run外初始化共享资源（如db := setupDB()），然后在并行子测试里直接用；会触发data race - 子测试名不能重复（比如用
i当 name），否则测试被覆盖、日志混乱、覆盖率统计失真 - 推荐用
t.TempDir()替代硬编码路径（如"./tmp"），路径天然隔离且自动清理
哪些测试能加 t.Parallel()，哪些绝对不能
判断标准只有一条：是否「不依赖外部可变状态、不修改全局环境、自身幂等」。
- 适合加：
TestParseJSON、TestValidateEmail、TestCalculateTax—— 纯计算、无 IO、输入输出确定 - 需谨慎加：
TestHandleHTTPRequest—— 必须用httptest.NewRequest+httptest.NewRecorder，禁用真实网络 - 绝对不能加：
TestWriteToFile（除非用t.TempDir()）、TestMigrateDB（SQLite:memory:也存在连接复用风险）、TestSetFlag（flag.Parse()非并发安全） - 调用
os.Setenv()或time.Sleep()的测试，Go 运行时会静默禁用并行
调试并行测试失败的关键动作
并行下日志交错、失败定位难，靠 print 调试基本无效；必须依赖 Go 原生机制和工具链。
- 必加
go test -race：它比日志更早暴露竞态，fatal error: concurrent map writes就是典型信号 - 临时去掉
t.Parallel()或用go test -v -run=^TestName$单独运行，快速验证是否为并发引发 - 错误信息里带
TestFoo/TestBar这种嵌套名，前提是子测试命名清晰（别全叫"case1"） - 有 goroutine 的测试，必须用
sync.WaitGroup或chan等待完成，不能靠time.Sleep—— 时间不可控，且会拖慢整个并发组
真正难的从来不是“怎么加 t.Parallel()”，而是识别出那些隐式共享的状态：包级变量、未关闭的 HTTP server、全局 logger、硬编码端口……它们藏在 init 函数里、包变量中、甚至第三方库的默认配置里。一旦漏掉一个，整个并行组就退化为串行，或者更糟——间歇性失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
