t.Parallel() 仅声明测试可并行，需配合 go test -p=N 才生效，且必须在测试函数内显式调用；未满足并发条件、存在共享状态或阻塞操作时，并行不会提速。
Go 的 t.Parallel() 不是“开启并行”，而是“声明可并行”——它只在 go test -p=N（或默认并发数）下才真正调度，并且必须由测试函数自己显式调用，否则所有测试仍串行执行。
为什么加了 t.Parallel() 却没变快？
常见错因是没理解它的触发条件：
- 测试文件里所有用到
t.Parallel()的测试函数，必须在同一包内、且不能有依赖顺序（比如共用全局变量、临时文件、端口等） - 未启用并发测试：默认
go test是单 goroutine 执行，需显式加-p=4或设置GOMAXPROCS无直接作用，真正控制的是-p参数（表示最大并行测试函数数） - 测试函数体里仍有阻塞操作，比如
time.Sleep(1 * time.Second)，即使并行，总耗时仍被最长那个拖住 - 父测试调用了
t.Parallel()，但子测试（如t.Run()内部）没再调，子测试仍串行
t.Parallel() 必须放在测试函数开头吗？
不是“必须”，但强烈建议放在第一行，否则可能引发竞态或行为异常：
- 如果在
t.Parallel()前执行了状态修改（如os.Setenv()、写文件、改全局 map），这些操作会被多个并行测试同时看到，极易出错 - Go 测试框架在调用
t.Parallel()后，会把该测试标记为“可调度”，若之前已执行副作用，就相当于“带状态并行”，违背设计初衷 - 示例错误写法：
func TestAPI(t *testing.T) { setupDB() // ❌ 千万别在这儿初始化共享资源 t.Parallel() // 晚了，setupDB 已污染环境 callEndpoint(t) }
如何安全地在并行测试中使用共享资源？
并行 ≠ 共享。要避免数据竞争，核心原则是：每个测试独占资源，或用同步机制隔离。
- 用
t.TempDir()替代硬编码路径：t.TempDir()每次返回唯一路径，天然隔离文件操作 - 用内存数据库代替真实 DB：比如
sqlmock或bolt/dbin-memory 模式，避免端口/文件冲突 - 网络端口：用
net.Listen("tcp", "127.0.0.1:0")让系统自动分配空闲端口，而不是固定写死:8080 - 真需要共享只读资源（如配置），确保初始化发生在
init()或测试主函数外，且不修改；写操作一律禁止
子测试（t.Run()）怎么并行？
每个 t.Run() 是独立测试节点，是否并行由其内部是否调用 t.Parallel() 决定，和父测试无关：
- 父测试调了
t.Parallel()，子测试不调 → 子测试仍串行执行 - 父测试没调，子测试调了 → Go 允许，但实际不会并行（因为父测试本身阻塞，子测试无法脱离其生命周期）
- 正确姿势：父测试不调
t.Parallel()，每个子测试自己调 —— 这样它们彼此独立、真正并行func TestMathOps(t *testing.T) { tests := []struct{ name string a, b int want int }{{"add", 2,3,5}, {"mul", 2,3,6}} for _, tt := range tests { tt := tt // ✅ 必须闭包捕获，否则循环变量复用 t.Run(tt.name, func(t *testing.T) { t.Parallel() // ✅ 每个子测试独立声明可并行 if got := op(tt.a, tt.b); got != tt.want { t.Errorf("got %v, want %v", got, tt.want) } }) } }
最常被忽略的一点：并行测试失败时，日志输出顺序是乱的，t.Log() 不再按代码顺序打印；调试时别依赖输出时序判断执行流，要用 t.Name() 显式标注上下文。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
