17370845950

Go并发测试关键在于暴露真实问题：用-go test -race检测竞态，-v查看详情；手动构造goroutine时用sync.WaitGroup控制生命周期，避免sleep等待，错误通过channel或原子变量收集。

Go 的 testing 包原生支持并发测试，但直接用 go test 跑并发逻辑容易漏掉竞态、死锁或时序问题。关键不是“能不能测”，而是“怎么设计才能暴露真实问题”。

用 -race 检测数据竞争

Go 自带的竞态检测器是并发测试的第一道防线，它能发现共享变量未加锁、map 并发读写等典型问题。

• 运行命令：go test -race -v ./...（加上 -v 看详细输出）
• 它会在运行时插桩，记录所有内存访问，一旦发现两个 goroutine 无同步地读写同一地址，立刻报错并打印调用栈
• 注意：开启 -race 后程序变慢、内存占用高，仅用于测试，不可用于生产
• 常见误报场景少，但若用 sync/atomic 正确操作整数，它不会误报；而对自定义结构体字段做原子操作，需确保用 atomic.Value 或显式同步

手动构造 goroutine + sync.WaitGroup 控制生命周期

单元测试里不能依赖“sleep 等待”，必须精确控制并发 goroutine 的启停和完成信号。

• 用 sync.WaitGroup 记录启动的 goroutine 数量，每个 goroutine 结束前调用 wg.Done()
• 主测试函数调用 wg.Wait() 阻塞等待全部完成，避免测试提前退出
• 别在 goroutine 里直接用 t.Fatal —— 它只影响当前 goroutine，主测试可能已结束。改用 t.Errorf + 共享错误 channel 或原子变量收集问题
• 示例片段：
  

  var wg sync.WaitGroup
  errCh := make(chan error, 10)
  for i := 0; i < 10; i++ {
    wg.Add(1)
    go func(id int) {
      defer wg.Done()
      if err := doWork(id); err != nil {
        errCh <- fmt.Errorf("worker %d failed: %w", id, err)
      }
    }(i)
  }
  wg.Wait()
  close(errCh)
  for err := range errCh {
    t.Error(err)
  }

用 testify/assert 或原生 t.Helper() 提升断言可读性

并发测试中失败位置难定位，辅助函数能减少样板代码、统一错误上下文。

• 给每个 goroutine 加唯一 ID 或 trace 标识，断言失败时带上该标识，比如：t.Errorf("worker-%d: expected %v, got %v", id, want, got)
• 用 t.Helper() 标记自定义检查函数，让错误行号指向调用处而非内部实现
• 避免在循环里反复调用 t.Fatalf —— 它会终止整个测试。优先用 t.Errorf 收集所有失败，最后统一判断是否要失败
• 若使用 testify/assert，注意其断言函数（如 assert.Equal）默认不中断执行，适合批量校验

模拟超时与取消：用 context.Context 和 time.AfterFunc

真实并发逻辑常涉及超时控制、主动取消，测试需覆盖这些边界路径。

• 不要用 time.Sleep 等待结果，改用 select + context.WithTimeout 显式设定等待窗口
• 测试取消场景时，创建 ctx, cancel := context.WithCancel(context.Background())，在适当时机调用 cancel()，验证被调用函数是否及时退出
• 用 time.AfterFunc 模拟延迟触发事件（如定时重试、心跳超时），比固定 sleep 更可靠
• 检查函数是否响应取消：启动 goroutine 执行任务，立即 cancel ctx，观察是否在合理时间内返回或清理资源

基本上就这些。并发测试不复杂但容易忽略时序和同步细节，核心是“可控、可观测、可复现”——用 -race 揭露隐患，用 WaitGroup 和 Context 控制流程，用结构化断言明确失败原因。