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<br>errCh := make(chan error, 10)<br>for i := 0; i < 10; i++ {<br> wg.Add(1)<br> go func(id int) {<br> defer wg.Done()<br> if err := doWork(id); err != nil {<br> errCh <- fmt.Errorf("worker %d failed: %w", id, err)<br> }<br> }(i)<br>}<br>wg.Wait()<br>close(errCh)<br>for err := range errCh {<br> t.Error(err)<br>}
用 testify/assert 或原生 t.Helper() 提升断言可读性
并发测试中失败位置难定位，辅助函数能减少样板代码、统一错误上下文。
立即学习“go语言免费学习笔记（深入）”；
- 给每个 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 控制流程，用结构化断言明确失败原因。
