go run -race 能暴露数据竞争，但仅当实际发生并发读写同一内存地址时才报错；其 warning 报告中关键三行是：write 行、previous read 行、created at 行，共同构成竞态证据链。
go run -race 能直接暴露数据串错的根源，但必须实际发生并发读写同一内存地址才会报；不加 -race 就完全静默，生产环境默认关闭。
go run -race 报 WARNING: DATA RACE 时该盯哪三行
每次报告里真正有用的只有三行，它们构成完整证据链：
-
Write at 0x00c000014098 by goroutine 7：当前写操作的位置和 goroutine ID -
Previous read at 0x00c000014098 by main goroutine：与之冲突的另一次访问（注意“Previous”不是时间先后，而是检测器记录顺序） -
created at ... main.go:12：goroutine 的启动点，90% 的循环变量捕获错误（如for i := range xs { go func() { use(i) }() }）靠这行定位
地址相同（如都是 0x00c000014098）才说明是同一变量；地址不同大概率是 padding 或不同字段，不是真竞态。
结构体指针被并发读写导致字段值错乱
典型场景不是 student.Name 被改乱，而是 tempStruct.student 这个指针变量本身被多个 goroutine 同时读（testCronFunc 里持续取值）和写（主线程赋新值）。
- 错误修复方式：只锁
Name或Age字段没用——竞争对象是student字段的地址值 - 正确做法：把对
tempStruct.student的读写都包在mu.Lock()/mu.Unlock()里 - 更推荐方案：用
atomic.Value存储*person，写入用Store(interface{})，读取用Load()后类型断言 - 注意：
atomic.Value不支持部分更新，不能单独改Name；存入类型必须一致，第一次Store(*person)，后续不能再Store(string)
复用同一块 []byte 底层数组引发缓冲区串错
这是最容易被忽略的底层串错来源：两个 goroutine 共享一个 buf := make([]byte, 1024)，一个调 conn.Read(buf)，另一个拿 buf 去 writeToDB(buf)——一旦 Read 覆盖了 buf，而 write 还没发完，数据就混了。
- 根本原因：
[]byte是 header + 底层数组指针，多个 goroutine 持有不同 header 但指向同一底层数组 - 简单修复：每个 goroutine 分配独立
buf，或用bytes.Buffer管理生命周期 - 进阶方案：用
sync.Pool复用[]byte，但必须确保Get后不再与其他 goroutine 共享 - 切忌：在 goroutine 中
append同一块buf后传给 channel ——append可能扩容并替换底层数组，原指针失效
最常被跳过的一步是：加了 -race 却没跑够轮次。竞态依赖调度时序，单次运行可能漏掉；务必用 go test -race -count=10 ./... 或 go run -race -gcflags="-l" main.go（禁用内联增加插桩密度）反复验证。另外，init 阶段启动的 goroutine、unsafe 或 CGO 操作，-race 无法覆盖，得靠设计规避。
