go test -race 不报错不等于并发安全，仅当真实交错读写同一堆内存地址时才触发；参数位置错误、goroutine 未等待、局部变量未逃逸等均导致漏检。
go test -race 不报错，不代表代码并发安全；它只在两个 goroutine 真实交错读写同一内存地址时才发声——没触发，就静默。
go test -race 参数位置写错就等于没开
竞态检测器对命令格式极其敏感：-race 必须紧接 go test 之后、包路径之前，否则被当作普通参数忽略，且不报任何警告。
- ✅ 正确：
go test -race ./、go test -race -v pkgname - ❌ 错误：
go test ./ -race（-race被当成本地路径）、go run main.go -race（-race变成你程序的 flag） - CI 中建议统一用
go test -race ./，避免因路径写法差异导致漏检
测试里没等 goroutine 结束，-race 就没机会报警
竞态不是“存在即报警”，而是“执行到冲突指令才记录”。如果测试启动 goroutine 后直接退出，那些未执行或未交错的读写根本不会被插桩监控。
- 必须用
sync.WaitGroup或chan struct{}显式等待所有 goroutine 完成 - 避免
time.Sleep：它不可控、拖慢测试、且不能保证竞态窗口打开；runtime.Gosched()在临界区前后插桩更有效 - 并发规模要够：10 个 goroutine 各调 1 次，远不如 50 个各调 100 次容易触发调度交错
局部变量没逃逸，-race 根本不跟踪
-race 只监控堆上内存访问。栈上未逃逸的变量（如函数内定义、未取地址、未传入 goroutine）不会被检测，哪怕逻辑上被多个 goroutine “共享”。
立即学习“go语言免费学习笔记（深入）”；
- 闭包捕获循环变量是高频陷阱：
for i := range xs { go func() { use(i) }() }→i是同一个栈变量，但 race detector 可能因未逃逸而漏报 - 修复方式：显式传参
go func(v int) { use(v) }(i)，或取地址让其逃逸（如&i传入） - 全局变量、结构体字段、切片底层数组元素、
new(T)分配的对象，才在 -race 监控范围内
修复后不重跑 -race 验证，等于没修
加了 sync.Mutex、改用 atomic.AddInt64、甚至换 chan 通信，都不代表竞态消失。唯一可信标准是 go test -race 零警告。
- 锁范围错误很常见：只锁了写操作，忘了读；或锁了大段含 IO 的逻辑，导致性能崩但读写交界处仍裸奔
- 混用原子与非原子操作会失效：比如用
atomic.StoreInt64写，却用普通=读，-race仍会报冲突 - 别信“本地跑通”——线上多核高负载下调度更乱，竞态窗口更大；修复后务必在相同环境重跑
go test -race
真正难的不是加锁或改 atomic，而是确认所有共享路径都被覆盖、所有变量都逃逸到了堆、所有 goroutine 都被同步等待——这些细节一漏，-race 就会安静地放过那个将来在线上凌晨三点 panic 的 bug。
