go race detector 只捕获运行时实际发生的竞态，需两个 goroutine 真正并发读写同一内存且调度交错；漏检包括漏锁、未覆盖路径、unsafe.pointer 访问；能稳定捕获 counter 增量竞争、map 并发读写、struct 字段无同步读写。
Go race detector 能抓到哪些竞态
它只捕获运行时实际发生的竞态，不是静态分析。也就是说，代码里有竞态不等于能被检测到——得真让两个 goroutine 同时读写同一块内存，且调度器恰好把它们交错执行了才行。
常见漏检场景：
— sync.Mutex 或 sync.RWMutex 用对了但漏锁（比如 defer 解锁但提前 return）
— 竞态发生在测试没覆盖的分支或极低概率路径上
— 使用 unsafe.Pointer 绕过 Go 内存模型，race detector 默认不跟踪这类访问
它能稳定捕获的典型模式：
— 一个 goroutine 写 counter++，另一个读 fmt.Println(counter)
— map 并发读写（哪怕只是两个 goroutine 同时 range + delete）
— struct 字段被多个 goroutine 无同步地读写（尤其是 bool/int 类型字段）
怎么开 race 检测跑测试
别在 CI 或生产环境用，只用于本地开发和测试阶段。开启方式很简单，加个 -race 标志：
立即学习“go语言免费学习笔记（深入）”；
go test -race ./...go run -race main.gogo build -race -o app .
注意几个关键点：
— 必须所有相关包一起编译，不能只对部分文件加 -race
— 会显著拖慢执行速度（通常 2–5 倍），内存占用也翻倍，所以别长期开着跑基准测试
— 它依赖运行时插桩，所以交叉编译（如 GOOS=linux go build -race）会报错，必须在目标平台原生构建
看到 race report 别直接改 sync 包
输出里带 Previous write at 和 Current read at 的堆栈，重点不是“哪里错了”，而是“哪两个 goroutine 在争什么”。先确认是不是真的共享状态需要并发访问。
常见误解和更优解：
— 把局部变量（比如函数内声明的 result）塞进 goroutine 闭包里共享：改用传参或返回值，而不是加 sync.Mutex
— channel 传指针导致接收方和发送方操作同一块内存：改成传值，或确保接收方只读不写
— 测试里用 time.Sleep 等 goroutine 结束：race detector 可能根本没机会触发，换成 sync.WaitGroup 或 select 等明确同步点
真正该加锁的地方，优先考虑 sync.Mutex 而不是 sync.RWMutex——后者容易因读锁未释放完就写入而掩盖问题，且读多写少场景才值得换。
为什么本地测不出 race 却在线上崩了
根本原因是调度差异：本地 CPU 核心少、负载低，goroutine 调度顺序更“顺”，竞态窗口小；线上高并发+多核，内存重排序和缓存不一致更容易暴露。
提升本地复现率的有效做法：
— 在可疑代码前后插入 runtime.Gosched()，强制让出时间片
— 用 for i := 0; i 多次运行测试，而不是只跑一次<br>— 在 CI 中固定用 <code>GOMAXPROCS=4（或更高）再跑 -race，模拟多核压力
还有一个硬伤：race detector 不检查系统调用（如文件 IO、网络读写）间的竞态，如果逻辑依赖外部状态（比如两个 goroutine 同时修改同一个临时文件），它完全无感。
真正难搞的永远是那些不触发 race detector 却又在特定时序下破坏数据一致性的逻辑，比如依赖某个字段写入顺序来决定后续行为——这种得靠形式化建模或者更细粒度的状态断言，不是加个 -race 就能兜住的。
