go run -race能可靠检测数据竞争，通过编译插桩和运行时监控定位读写冲突点，需在开发测试阶段启用，配合正确同步机制（如锁住变量本身、使用atomic.value或channel）避免误用。
go run -race 能立刻暴露读写冲突点
只要存在多个 goroutine 同时读写同一变量且无同步，go run -race 就大概率能抓到。它不是概率检测，而是编译时插桩 + 运行时监控，对每个内存访问做标记和比对。
常见触发场景包括：counter++、共享结构体字段被 goroutine 异步修改、闭包中捕获循环变量（如 for i := range xs { go func() { fmt.Println(i) }() }）、配置指针被热更新与读取同时操作。
- 必须加
-race才启用，不加就完全静默 —— 生产环境默认关闭，开发/测试阶段务必开启 - 输出里带
Read at 0x...和Previous write at 0x...的地址和行号，直接定位到两处并发访问位置 - 注意：如果竞争发生在 init 阶段或极早期 goroutine，可能因检测器尚未就绪而漏报
sync.Mutex 不是万能锁，得锁对变量
用 sync.Mutex 修复时，最容易犯的错是“锁了但没锁住真正被争抢的内存”。比如原例中 tempStruct.student 是一个指针，go tempStruct.testCronFunc() 里持续读 ts.student，而主线程后来改的是这个指针本身（tempStruct.student = &person{...}），不是它指向的内容。
这时只锁 student.Name 或 student.Age 没用 —— 竞争对象是 student 这个字段的地址值。
- 正确做法：把
student字段读写都包在mu.Lock()/Unlock()里，或者改用原子指针（atomic.Value）承载*person - 别在方法内 new 一个局部
sync.Mutex，必须是结构体字段或包级变量，否则每次调用都是新锁，毫无互斥效果 - 读多写少场景下，
sync.RWMutex可提升并发读性能，但写操作仍需Lock()，不能只用RUnlock()
atomic.Value 更适合替换整个指针或结构体
当你要安全地更新一个指针（如 *person）或不可变结构体（如 config），atomic.Value 比 sync.Mutex 更轻量、更语义清晰。它底层用的是 CPU 原子指令，不涉及操作系统调度开销。
但它只支持「整体存/取」，不能部分更新字段。例如不能用 atomic.Value 单独改 person.Name，只能整块替换 *person。
- 写入用
Store(interface{})，读取用Load() interface{}，返回值需类型断言 - 存入的值必须是可比较的（满足 Go 的 comparable 约束），切片、map、func 不行；若要存 map，得包装成 struct 或用
sync.Map - 注意类型一致性：第一次
Store是*person，后续就不能Storestring，否则 panic
goroutine 间传值优先用 channel，而不是共享内存
很多 Data Race 其实源于设计惯性：下意识把变量设成全局或结构体字段，再靠锁保护。但 Go 的哲学是「不要通过共享内存来通信，而应通过通信来共享内存」。
比如定时打印学生信息，与其让 goroutine 直接读结构体字段，不如用 channel 接收新 *person：
ch := make(chan *person, 1)
go func() {
for p := range ch {
fmt.Println(p)
}
}()
// 主线程发新值
ch
- channel 天然线程安全，无需额外同步
- 发送端控制节奏，接收端不会看到中间态（比如只改了 Name 没改 Age）
- 注意缓冲区大小：无缓冲 channel 会阻塞发送，有缓冲则可能丢数据，选 1 通常最稳
Data Race 最难缠的地方不在修复，而在“它不总发生”。一次测试过、压测过、上线跑三天都没事，不代表没有；加了 -race 报错，删掉又不报 —— 这恰恰说明问题真实存在，只是执行路径没撞上。别信“我试了好多次都正常”，信 -race 的输出，信内存模型的约束。
