go race detector仅检测运行时实际发生的竞态，要求不同goroutine同时对同一内存地址进行至少一次写操作；读-读不报，写-写、读-写、写-读均报；结构体字段、切片底层数组、map元素等地址重叠即可能触发。
Go race detector 能抓到哪些未同步的共享变量访问
它只检测运行时实际发生的竞态，不是静态分析；没执行到的并发路径不会报。比如两个 goroutine 都写 counter，但其中一个分支永远不进，go run -race 就不会触发警告。
- 必须是「不同 goroutine 同时」对同一内存地址做「至少一个是写」的操作
- 读-读不报（即使没加锁），写-写、读-写、写-读都报
- 结构体字段、切片底层数组、map 元素、全局变量、闭包捕获的局部变量，只要地址重叠就可能中招
- 注意：
sync.Mutex保护的是临界区逻辑，不是变量名；漏锁、错锁（锁 A 却改 B）、或用值拷贝的 mutex 都无效
最常踩坑的三种“看起来线程安全”写法
这些代码在本地跑十次都正常，一上压测环境就 panic 或返回错误值，因为 race detector 没开，或者没覆盖到竞争路径。
for i := 0; i —— 闭包捕获的是变量 <code>i的地址，所有 goroutine 共享同一个i，循环结束时i已是 10，结果total很可能等于 100 而非 45-
var m map[string]int; go func() { m["a"] = 1 }(); go func() { delete(m, "a") }()—— map 非并发安全，即使只读写不同 key 也会 crash -
type Config struct{ Port int }; c := Config{Port: 8080}; go func() { c.Port = 8081 }()—— 值类型传参后修改的是副本，原c.Port不变，但若传的是&c，又没加锁，就真出问题
用 sync.Mutex 修复时，锁粒度和位置怎么选
锁太粗会串行化，锁太细可能漏保护；关键是「所有访问共享变量的路径都必须经过同一把锁」。
- 别在函数入口加锁然后 defer 解锁——如果中间有阻塞调用（如 HTTP 请求），会拖慢其他 goroutine
- 避免在循环内反复加锁/解锁：
for _, v := range data { mu.Lock(); shared = append(shared, v); mu.Unlock() }应该把整个循环包进去 - map + mutex 组合推荐用
sync.RWMutex：读多写少时，RLock/RUnlock允许多个 reader 并发，比普通Lock更高效 - 注意：mutex 字段必须导出（首字母大写）且不能被复制；结构体里嵌入
sync.Mutex后，该结构体变量只能取地址使用，否则每次传参会复制一个新 mutex
race detector 报错信息怎么看、怎么定位源头
报错末尾的 goroutine stack trace 是关键，但第一眼看到的往往不是你写的代码，而是标准库或 runtime 的调用帧。得往上翻，找最后一个你自己包里的文件行号。
立即学习“go语言免费学习笔记（深入）”；
- 典型报错开头像：
WARNING: DATA RACE Write at 0x00c000010240 by goroutine 7: ... Previous read at 0x00c000010240 by goroutine 6:—— 地址相同说明是同一变量 - stack 中出现
runtime.goexit或internal/poll.(*FD).Write别慌，继续往上找，直到看到类似myproject/handler.go:42 - 如果报错里只有 test 文件，说明测试并发启动了 goroutine 但没等它们结束，主 goroutine 就退出了，用
sync.WaitGroup或time.Sleep（仅测试）补上等待 - CI 环境跑
-race变慢是正常的，但若超时，优先检查有没有死锁或无限循环，而不是关掉 race 检测
真正麻烦的不是发现 race，而是它只在特定调度顺序下出现；哪怕加了锁，如果漏了某条路径（比如 error 分支没 unlock），问题还在那里，只是更难复现。
