Go race detector 不能测出所有并发 bug，仅检测内存竞争，对死锁、逻辑错误等无效；需配合 -race 测试但不可依赖其覆盖全部问题，且要注意原子操作误报和 CI 中使用 -count=1 避免缓存掩盖竞争。
Go race detector 能不能直接测出所有并发 bug
不能。它只检测内存竞争（即多个 goroutine 同时读写同一变量且无同步），对逻辑错误、死锁、活锁、顺序依赖错误完全无感。比如两个 goroutine 按错序执行 send 和 receive，race detector 不报错，但程序行为已错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须配合
-race运行测试，但别把它当“并发测试完成”的标志 - 开启后注意 false positive：某些合法的低层原子操作（如用
sync/atomic手动管理）可能被误报，需结合代码判断 - CI 中固定加
go test -race -count=1（-count=1避免缓存掩盖竞争）
怎么写可重复、不 flaky 的并发单元测试
核心是控制不确定性：避免依赖时间、调度顺序、goroutine 启动/退出时机。重点不是“让它跑通”，而是“让它在各种调度下都正确”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.WaitGroup或chan struct{}显式等待 goroutine 完成，别用time.Sleep - 测试 channel 操作时，优先用带缓冲的 channel 或 select + default，避免阻塞导致超时失败
- 对共享状态做断言前，确保所有 goroutine 已退出（例如
wg.Wait()后再检查len(queue)） - 有意制造竞争场景：比如让 10 个 goroutine 并发调用
increment()，最后检查结果是否等于 10
testify/assert 在并发测试里有什么坑
它的 assert.Equal 等函数本身不是并发安全的 —— 如果多个 goroutine 同时触发失败断言，会并发写 stdout 或 panic，导致测试日志混乱甚至崩溃。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有断言必须在主线程（test 函数内）做，goroutine 内只负责计算、发送结果到 channel
- 推荐模式：
results := make(chan int, 10)→ 启动 goroutine 写results→for i := 0; i - 避免在 goroutine 里调用
t.Fatal或t.Error：它们不是 goroutine-safe，会导致 panic: “testing: t.Fatal called from non-main goroutine”
如何验证 goroutine 泄漏
goroutine 泄漏不会立刻报错，但会导致内存缓慢增长、句柄耗尽。关键指标是测试前后 runtime.NumGoroutine() 的差值是否为 0。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在测试开头记下初始数量：
before := runtime.NumGoroutine() - 测试逻辑执行完、显式关闭所有 channel / stop 所有后台任务后，再等一小段时间（如
time.Sleep(5 * time.Millisecond)）让 goroutine 有机会退出 - 再取
after := runtime.NumGoroutine()，用assert.LessOrEqual(t, after-before, 0)校验 - 注意：标准库中有些 goroutine 是长期存活的（如
http.DefaultClient内部的 keep-alive 管理器），测试时需排除干扰，最好用干净的&http.Client{Transport: &http.Transport{}}
真正难的不是让并发测试“跑起来”，而是让它们在 CI 上稳定通过、在重构后仍能暴露问题。多数失败其实源于测试本身对调度的隐式假设，而不是被测代码。
