go run -race 漏检是常态，因仅对实际执行路径插桩，不覆盖 init 中退出的 goroutine、条件分支、unsafe/CGO、无交叠访问等场景；需用 go test -race -test.stress 配合多路径测试和调度扰动才能有效暴露竞态。
go run -race 不报错 ≠ 没有 data race，只是它没“看见”——漏检是常态，不是 bug。
为什么 go run -race 有时完全沉默，但程序行为却诡异？
因为 race detector 只对实际执行到的内存访问路径插桩，不是静态扫描。以下情况它根本不会覆盖：
-
init函数里启动的goroutine，若在main开始前就退出或未触发竞争，检测器压根不介入 - 带条件分支的并发逻辑（比如
if debug { go f() }），测试时没进该分支，竞态被跳过 - 用
unsafe.Pointer或CGO绕过 Go 类型系统直接操作内存，race detector 失去跟踪能力 -
goroutine启动后瞬间写一次就退出，而主 goroutine 的读发生在它之前，两次访问没交叠，检测器判定“无竞争”
go test -race 配合 -stress 才是真压力筛子
单次 go run -race 覆盖面太窄，必须用测试驱动+调度扰动才能暴露隐藏竞态：
- 用
go test -race ./...替代go run -race，确保所有测试路径都被插桩 - 加
-test.stress="Duration=5s"强制多轮重试，打乱 goroutine 启动/退出顺序，提高竞态触发概率 - 避免只测 happy path；给并发逻辑加随机 sleep、不同负载比例、边界值输入，让调度器“手滑”
看懂 WARNING: DATA RACE 输出里的三行铁证
每次报告里只有这三行能帮你定位根源，缺一不可：
-
Write at 0x... by goroutine N：当前写操作的地址和 goroutine ID -
Previous read/write at 0x... by goroutine M：“Previous”不是时间先后，而是检测器记录的上一个相关访问；地址相同才说明是同一变量 -
created at行：暴露 goroutine 启动点，90% 的闭包捕获错误（比如for i := range xs { go func() { use(i) }() }）靠这行揪出
修复前先问：这个变量真需要共享吗？
很多“串错”本质是设计假设错了，不是锁或原子操作没用好：
- 检查是否把本该 per-goroutine 的状态（如临时缓冲、中间计数）误放全局变量
- 考虑用 channel 汇总结果，而非多个 goroutine 直接改同一字段
- 用
sync/atomic替代sync.Mutex仅限基础类型简单读写；复杂结构别硬套，容易漏字段 - 避免在 defer 中 unlock 错误的 mutex，或在 panic 后没 unlock——这类问题
-race不报，但会导致死锁或数据滞留
真正难的不是加锁，是判断哪块内存不该出现在多个 goroutine 的视野里。地址相同的两行访问，才是竞态的起点；地址不同，再像也不构成 data race。
