根本原因是测试间存在隐式共享状态，如全局变量、固定路径临时文件或未隔离的数据库连接；t.parallel()仅启用goroutine并发，不解决资源竞争，争抢导致串行阻塞而退化为“假并发”。
Go test 并发执行 t.Parallel() 为什么没加速？
根本原因通常是测试函数之间存在隐式共享状态，比如共用全局变量、临时文件路径或未清理的数据库连接。t.Parallel() 只是让测试函数在 goroutine 中并发运行，不解决资源竞争；一旦测试因争抢资源而串行阻塞（比如互斥锁等待、文件写入冲突），实际执行就退化成“假并发”。
- 检查是否所有测试都调用了
t.Parallel()—— 漏掉一个，整个测试组都会被它拖慢 - 确认没有在测试中读写未加锁的包级变量，例如
var db *sql.DB被多个测试复用却未隔离 - 避免使用固定路径的临时文件，
os.Create("test.db")会导致冲突；改用os.CreateTemp("", "test-*.db") - 如果用了
testing.TB.Cleanup()，确保清理逻辑本身是幂等且无竞态的
什么时候不该用 t.Parallel()
不是所有测试都适合并行。核心判断标准是：该测试是否依赖外部不可重入资源，或自身逻辑是否非幂等。
- 涉及真实网络请求（如调用本地
http://localhost:8080）且服务端无并发处理能力时，会压垮端点 - 操作单个 SQLite 文件（即使加了
sqlite3.Open("file.db?_busy_timeout=5000")）仍可能触发锁等待 - 测试里调用了
time.Sleep(100 * time.Millisecond)且期望精确时序，结果被调度器打乱 - 使用了
flag.Parse()或修改了os.Args—— 这些是全局状态，多 goroutine 同时改会 panic
t.Parallel() 和 -p 参数的关系
t.Parallel() 控制测试函数是否允许并发执行，而 go test -p=N 控制的是测试包级别的并行 worker 数量，默认是 GOMAXPROCS。两者叠加才决定最终并发度。
- 单个测试函数内调用
t.Parallel()，但go test -p=1，那所有测试仍是串行跑 - 没写
t.Parallel()，但-p=4，也不会并发——因为 Go 测试框架只对显式声明并行的测试启用 goroutine 调度 - 推荐组合：代码里加
t.Parallel()，命令行用go test -p=4 -race验证竞态，上线 CI 可设-p=2避免资源过载
并发测试失败时如何快速定位竞态？
最直接有效的方式是开启 -race 检测器，它能在运行时捕获绝大多数内存访问竞态，比靠日志猜快得多。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go test -race -v ./...，一旦出现竞态，会输出类似Read at 0x00c00012a000 by goroutine 7的详细栈 - 注意：开启
-race后测试变慢、内存占用翻倍，仅用于本地调试，不要在 CI 长期开启 - 如果
-race没报错但行为不稳定，大概率是外部依赖（如 Redis、磁盘 IO）造成的逻辑竞态，需检查 setup/teardown 是否完备 - 临时加
runtime.Gosched()强制调度切换，有时能暴露隐藏的时序 bug，但只是辅助手段
真正难的不是加 t.Parallel()，而是让每个测试彻底“干净”——没有隐式依赖、没有跨测试残留、没有时间或资源假设。这点容易被忽略，但决定了并发是否真能提速。
