Go测试中如何处理并发_Go并发测试注意事项

t.Parallel() 仅声明子测试可并发执行，不保证线程安全；必须确保被测代码自身无竞态，共享资源需加锁或隔离，务必配合 go test -race -count=1 暴露并修复数据竞争。

怎么用 t.Parallel() 才不踩坑

标记测试为并行不是加一行 t.Parallel() 就完事——它只表示“这个子测试可与其他 t.Parallel() 测试并发跑”，但不会自动同步共享状态。常见错误是多个并行子测试共用同一个全局变量或未加锁的 map，结果测试偶尔 panic 或断言失败。

• 必须确保被测代码本身线程安全，t.Parallel() 不是“修复竞态”的开关，而是“暴露竞态”的放大器
• 子测试间不要通过包级变量通信；如需共享资源（比如初始化一次的 mock DB），用 t.Cleanup() 或在非并行的外层 t.Run() 中完成 setup
• 避免在并行测试里调用 time.Sleep() 等靠时间等待的逻辑——调度不可控，容易误判超时或漏检查

为什么必须加 -race，而且不能只跑一次

go test -race 是 Go 并发测试的底线。不加它，90% 的数据竞争（比如两个 goroutine 同时写一个 int 字段）根本不会报错，只会静默出错：值被覆盖、计数少加、缓存返回旧数据……这些在单次运行中极难复现，但上线后高频请求下必现。

• 竞态检测有运行时开销，所以默认关闭；CI 和本地验证阶段务必启用：

  go test -race -count=1 ./...

• -count=1 很关键——防止测试缓存复用掩盖问题（比如第二次跑时 map 已初始化，竞态没触发）
• 看到 WARNING: DATA RACE 输出时，别改测试去绕过，要立刻修被测代码：加 sync.RWMutex、换 atomic、或重构为无共享设计

WaitGroup 和 channel 哪个更适合收尾验证

判断“所有 goroutine 是否真执行完了”，用 sync.WaitGroup 最直接；但若要验证“输出顺序”“响应内容”或“是否提前取消”，channel 更可控、更符合 Go 的并发哲学。

Flowstep

AI界面设计工具，通过对话几秒内创建UI设计图、线框图和流程图

下载

• 用 WaitGroup 时，记得 defer wg.Done() 放在 goroutine 内部最开头，防止 panic 导致漏调用
• 用 channel 收集结果时，别忘了设缓冲或用 select 配合 default / timeout，否则可能卡死：

  select {
  case result := <-ch:
      results = append(results, result)
  default:
      t.Fatal("no result received")
  }

• 涉及上下文取消（如 context.WithTimeout）的测试，必须验证 goroutine 是否真退出——光 close channel 不够，得确认它不再往 channel 写，也不再持有锁

包级并发冲突：为什么 -p=1 比 -parallel 0 管用

当测试跑在 CI 上突然失败，报错像 “database is locked” 或 “file already exists”，大概率不是代码问题，而是 go test ./... 默认并发执行多个包，彼此争抢共享资源（如 SQLite 文件、临时端口、全局注册表）。

• -parallel 0 只控制单个测试文件内子测试的并行度，对跨包并发无效
• -p=1 强制串行执行每个包，真正切断包间干扰：

  go test -p=1 ./pkg/cache ./pkg/db

• 如果必须并发跑包（比如加速），就改用隔离方案：每个包测试用随机端口、独立内存数据库、或 t.TempDir() 创建专属临时路径