go test -race 是官方唯一推荐的竞态检测方式，通过运行时插桩监控内存读写，需配合真实并发测试触发，命令顺序必须正确，修复后须再次验证零警告。

go test -race 是唯一靠谱的检测方式

别信静态分析或“看代码觉得没问题”——Go 的竞态（data race）只在真实并发执行时暴露，go test -race 是官方唯一推荐、开箱即用的运行时检测手段。它不是预测，而是插桩监控：每个内存读写都被记录，一旦发现“goroutine A 写、goroutine B 读/写同一地址且无同步”，立刻报错。

• 必须用测试触发并发：单纯 go run -race main.go 很难复现，因为启动时机、调度不可控；而 go test -race 可精确控制 goroutine 数量、启动节奏和共享变量访问频率
• 测试要真正“打起来”：比如对一个计数器并发调用 1000 次 Inc()，而不是只启 2 个 goroutine 跑一次
• 别依赖结果值判断是否安全：c == 1000 通过 ≠ 没竞态；只有 go test -race 不报警，才算过关

命令写错顺序就等于没开检测

-race 必须紧跟在主命令之后、包路径之前，顺序错就静默失效。常见错误写法：go run main.go -race（-race 被当成了程序参数）、go test ./ -race（位置靠后，Go 忽略）。

• 正确写法只有三种典型模式：go test -race ./（推荐，覆盖整个模块），go test -race -v ./（加 -v 看详细日志），go test -race pkgname（指定包）
• 构建二进制用于压测：用 go build -race -o app .，但注意它只支持 amd64 和 arm64，交叉编译到 32 位会失败
• CI 流水线中务必固定使用 go test -race ./，避免漏掉新引入的竞态

看懂竞态报告比定位 bug 还重要

报错不是堆栈异常，而是一组“冲突快照”：两个 goroutine 在相近时间访问了同一内存地址，检测器记录下它们各自的调用栈。关键不是“谁先谁后”，而是“没同步”。

• 典型输出里 Write at 0x00c0000a0060 by goroutine 7 和 Previous read at 0x00c0000a0060 by goroutine 6 表明是同一个变量地址被并发读写
• 行号精准到 main.go:12，直接跳转就能看到问题语句，比如 counter++ 或 m["key"] = val
• 别把 Previous write 当成时间先后——竞态的本质就是顺序不确定，检测器只是按自己记录顺序命名而已

修复后必须再跑一次 -race 验证

加了 sync.Mutex、改用 atomic.AddInt64 或换成 chan，不等于问题消失。锁

没加对位置、原子操作没覆盖全部路径、channel 缓冲区溢出，都可能留下残余竞态。

• 最简验证：把修复后的代码再跑一遍 go test -race，必须零警告
• 注意闭包陷阱：循环中启动 goroutine 时，用 for i := range xs { go func() { use(i) }() } 会导致所有 goroutine 共享最后一个 i 值，-race 通常能抓到这类读写冲突
• sync.Pool 不是银弹：它只保证 Get/Put 自身线程安全，如果放进去的对象内部有可变状态，仍需额外同步

竞态检测本身不耗脑力，但读懂报告、写对测试、验证修复效果，这三步环环相扣。很多人卡在“以为修好了”，其实只是没再触发——go test -race 不报警，才是唯一的验收标准。