并发测试必须用 go test -race，它是验证并发安全的必选项；需覆盖真实调用路径、控制 goroutine 交错执行以暴露竞态，仅用于测试环境。

并发测试必须用 go test -race

Go 自带的竞态检测器（race detector）是验证并发安全最直接有效的手段。不启用它，绝大多数数据竞争根本不会暴露——哪怕压测时偶尔 panic，也可能是其他原因掩盖了真正的竞态。它不是可选项，是必选项。

常见错误现象：本地跑单测全绿，CI 或线上偶发 panic / 数据错乱 / goroutine 泄漏；go run main.go 没问题，但 go run -race main.go 立刻报 WARNING: DATA RACE。

• 必须在测试命令中显式加 -race：例如 go test -race -v ./pkg/...
• 不能只测单元函数，要覆盖真实调用路径——比如一个 Counter.Inc() 方法，得在多个 goroutine 里并发调用它
• 竞态检测会显著拖慢执行速度（约 2–5 倍），且增加内存占用，所以仅用于测试环境，不可开启于生产构建

手写并发测试用例要控制 goroutine 数量和同步点

盲目起成百上千 goroutine 并不等于测得更严。关键在于制造「冲突窗口」：让多个 goroutine 在共享变量的读写之间交错执行。这需要主动引入等待、延迟或信号协调，否则调度器可能让它们串行执行，漏掉竞态。

使用场景：验证一个 sync.Map 替换原生 map 后是否真能避免 panic；或确认自定义的 AtomicCounter 在高并发下值准确。

• 用 sync.WaitGroup 确保所有 goroutine 启动后再统一开始操作，避免启动时间差干扰
• 避免用 time.Sleep 做同步——精度低、不稳定；改用 chan struct{} 或 sync.Once 控制起始时机
• 典型结构：

  var wg sync.WaitGroup
  start := make(chan struct{})
  for i := 0; i < 100; i++ {
      wg.Add(1)
      go func() {
          <-start // 等待统一指令
          defer wg.Done()
          counter.Inc()
      }()
  }
  close(start) // 所有 goroutine 同时开始
  wg.Wait()

别忽略 sync.Pool 和 sync.Once 的隐式并发风险

sync.Pool 和 sync.Once 本身线程安全，但它们的使用方式常埋雷。比如把非线程安全对象放进 Pool，再在不同 goroutine 中取出来直接复用；或误以为 Once.Do 能保护整个初始化块里的所有共享状态。

典型错误现象：sync.Pool.Get() 返回的对象内部含未加锁的 map 或 slice，后续并发修改导致 panic；Once.Do(func(){ initDB(); initCache() }) 中 initCache() 依赖尚未完成初始化的 initDB() 结果，引发 data race。

• sync.Pool 只保证 Get/Put 操作安全，不保证你放进去的对象本身安全——对象内若含可变状态，仍需自行加锁或 clone
• sync.Once 只确保函数体执行一次，不提供对函数内部所访问变量的读写保护；如有多个全局变量需协同初始化，应封装进一个结构体并用 mutex 控制整体访问
• 测试时，对 Pool 的用法要覆盖「Get → 修改 → Put → Get」完整生命周期，并在多 goroutine 下交叉执行

第三方工具如 gomock 或 testify 不解决竞态问题

mock 框架能帮你隔离依赖、控制返回值，但对并发安全零帮助。它们运行在单 goroutine 下模拟行为，完全绕过调度器的真实交错逻辑。用 mock 测出来的“并发通过”，往往只是假阳性。

真正要验证的，永远是实际数据结构在 runtime 调度下的表现——比如 sync.RWMutex 是否真能允许多读单写，atomic.Value 的 Load/Store 是否在指针重绑时不出现中间态。

• mock 可用于验证「逻辑分支是否走到」，但不能替代 -race 或手写 goroutine 用例
• 如果被测代码重度依赖外部服务，应先抽离并发敏感部分（如状态更新、缓存操作）单独测试，再集成
• 性能敏感路径（如高频计数器）建议额外做基准测试：go test -bench=. -benchmem -race，观察竞态检测开启后性能衰减是否可接受

并发安全不是“写了 mutex 就万事大吉”，而是每一处共享变量的每次读写，都要经得起 -race 的锤炼和多 goroutine 的真实交错。最容易被忽略的，往往是那些看起来“只读”或“只初始化一次”的代码段——它们恰恰最容易在竞态检测器下露出马脚。