不加锁的全局变量读写在并发测试中必然暴露竞态，go test -race 是唯一可靠、开箱即用的验证手段；加锁后仍需覆盖读写混合场景，否则容易漏掉 rwmutex 误用或 defer 遗漏导致的死锁。
直接上结论：不加锁的全局变量读写在并发测试中必然暴露竞态，go test -race 是唯一可靠、开箱即用的验证手段；加锁后仍需覆盖读写混合场景，否则容易漏掉 RWMutex 误用或 defer 遗漏导致的死锁。
怎么用 -race 快速发现未加锁的竞态问题
Go 自带的竞态检测器不是可选项，是必选项。它能在运行时动态追踪所有共享内存访问，精准定位哪一行读、哪一行写触发了冲突。
-
go test -race必须配合实际并发调用，比如启动多个 goroutine 修改同一变量，单纯单测不会触发竞态检测 - 错误输出形如：
Read at 0x00c000010240 by goroutine 7: ... Write at 0x00c000010240 by goroutine 8: ... Previous write at 0x00c000010240 by goroutine 6:—— 地址和 goroutine 编号就是最直接的线索 - 注意：-race 会显著拖慢执行速度（通常 2–5 倍），但这是值得的代价；CI 环境中建议只对关键模块启用
加了 sync.Mutex 为什么测试还是失败？常见漏点
加锁本身不等于安全，关键在「临界区是否完整覆盖」以及「Unlock 是否总能执行」。
- 忘记
defer mu.Unlock()，而是写成裸mu.Unlock()：一旦函数中途return或 panic，锁就永远拿不下来 - 临界区遗漏字段：比如全局结构体
type Config struct { A int; B string }，只锁了A的读写，却直接赋值cfg.B = "new"—— 这部分仍处于竞态 - 锁对象错位：用局部
sync.Mutex{}替代包级变量，每个 goroutine 拿到的是自己的锁，完全无效 - 锁粒度太粗：整个 handler 函数都包在
mu.Lock()里，HTTP 超时、日志写入等非共享操作也被阻塞，测试时表现为高延迟而非错误，但本质是性能型 bug
读多写少场景下，RWMutex 测试要特别注意什么
sync.RWMutex 不是 sync.Mutex 的“升级版”，它是读写语义分离的专用工具；测试时必须区分验证读路径和写路径。
- 并发读不阻塞：起 100 个 goroutine 同时调用
rw.RLock()+defer rw.RUnlock()，应无等待、无 panic - 读写互斥：一个 goroutine 持有
rw.Lock()时，其他任何rw.RLock()或rw.Lock()都必须阻塞，可通过time.AfterFunc+ 计时验证是否超时 - 禁止混用：不能在持有
rw.RLock()的 goroutine 中调用rw.Lock()—— 这会导致死锁，-race不报，但测试会卡住 - 注意零值：
var rw sync.RWMutex可直接使用，无需显式初始化；但若嵌入结构体，需确保该结构体自身不是被多次复制（如作为 map value 传值）
测试中绕不开的边界：Once、channel、map 非原子操作
全局变量不只是基础类型，还常包含 sync.Once、chan、map 等复合结构，它们各自有隐含的并发规则。
-
sync.Once只保证Do内函数执行一次，但不保护其内部操作 —— 如果once.Do(func(){ loadConfig() })里修改了另一个全局map，那个map仍需额外加锁 -
chan本身并发安全，但「从 chan 读出数据后存到全局 map」这一步仍是竞态点，锁必须覆盖到 map 写入完成 -
map不能直接并发读写：即使只读，若另一 goroutine 正在扩容（triggered by write），也会 panic；所以读也必须受锁保护，除非用sync.Map - 测试时别只看最终值，还要观察 panic：比如
fatal error: concurrent map read and map write就是典型未锁 map 的证据
真正难的不是加锁，而是判断「哪里该加、加多大、加哪种」；测试跑过只是起点，-race 报警、goroutine 卡死、map panic、数值偏差——这些信号比代码有没有 Lock() 更真实。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
