开启 go race detector 必须使用 go run -race 或 go test -race，否则完全不生效；它依赖编译器插桩和运行时检测，不进行静态分析，ci/cd 中必须启用并多次运行测试。
Go race detector 怎么开，不开就等于没防
不启用 go run -race 或 go test -race，代码里写再多同步逻辑也白搭——race detector 是编译器插桩+运行时检测，关掉就完全不工作。它不会静态分析，也不依赖你加注释或文档。
常见错误现象：go run main.go 没报错，但加上 -race 立刻爆出 Read at 0x... by goroutine X / Previous write at 0x... by goroutine Y；或者压测时偶发 panic，本地单跑却稳如老狗。
- CI/CD 流水线必须加
-race，哪怕慢 2–3 倍也要跑一次 - 测试用例里别只测功能正确性，
go test -race -count=10多跑几遍，竞争问题常在多次调度后才暴露 - 注意：CGO 开启时
-race会禁用，得关掉 CGO 或换方案
哪些变量最容易被 race detector 抓到
不是所有指针都会出问题，而是「多个 goroutine 同时读写同一内存地址」且无同步约束。最典型的是全局变量、闭包捕获的局部变量、结构体字段被并发修改。
使用场景举例：HTTP handler 共享一个 map[string]int 计数器，没加 sync.RWMutex；或者启动多个 goroutine 循环修改同一个 struct 的 count 字段。
立即学习“go语言免费学习笔记（深入）”；
-
sync.Map能躲过部分检测，但它不是万能替代品——只适合读多写少，且不能原子更新复合逻辑（比如“先查再增”） - 切片底层数组被多个 goroutine 写入不同索引？仍可能 race：底层
array地址相同，append触发扩容时更危险 - 接收
*T参数的函数被并发调用？只要内部改了T的字段，且调用方传的是同一个实例指针，就 race
用 channel 替代指针共享，真的安全吗
channel 不是银弹。它只保证「发送/接收动作本身」的原子性，不保证业务逻辑的原子性。如果多个 goroutine 通过 channel 传递指针，又在各自 goroutine 里直接改指向的值，race detector 照样报。
错误写法示例：ch ，然后两个 goroutine 从 <code>ch 收到同一个 *Data，各自执行 data.Field++ —— 这就是标准的 data race。
- 正确做法是：传值（
ch ），或传不可变结构；若必须传指针，确保只有唯一 goroutine 拥有写权限（比如用 channel 控制所有权转移） - 别用 channel 当锁使：比如起个 goroutine 专门处理某个对象，其他 goroutine 都往它发命令——这可行，但要小心命令本身是否带可变状态
- goroutine 泄漏比 race 更难查，别为了躲 race 盲目塞 channel
为什么 atomic 包有时还是不够用
atomic 只保基本类型（int32、uint64、unsafe.Pointer）的单操作原子性。一旦涉及多个字段联动、条件判断+更新、或结构体整体替换，atomic 就力不从心。
比如想实现“如果 count atomic.LoadInt32 和 atomic.AddInt32 分两步走，中间就被别的 goroutine 插入修改了。
-
atomic.Value可以安全存取任意类型指针，但仅限「整存整取」，不能对里面字段做原子操作 - 需要复合逻辑时，
sync.Mutex或sync.RWMutex仍是首选；别硬套atomic导致逻辑漏洞 - 注意：
atomic操作不提供内存屏障以外的同步语义，和chan或mutex的 happens-before 关系不同，混用容易误判
race detector 能发现大部分低级错误，但没法替你设计并发模型。真正难的不是“怎么加锁”，而是“哪些状态该归谁管、什么时候移交、失败了怎么回滚”。这些得靠代码边界划清楚，而不是靠工具兜底。
