sync.RWMutex适用于读多写少场景，如配置缓存、路由表；写频繁时反比Mutex慢；需配对使用RLock/RUnlock，避免死锁与panic，嵌入结构体时必须用指针接收器。
sync.RWMutex 什么时候该用，而不是 plain sync.Mutex
读多写少的场景下，sync.RWMutex 才有意义；如果写操作频繁（比如每秒几十次以上），它反而比 sync.Mutex 更慢，因为多了读锁计数和唤醒开销。
典型适用场景：配置缓存、路由表、内存索引映射（如 map[string]*User）这类「几乎只读，偶尔更新」的数据结构。
- 别在单 goroutine 里用 —— 它解决的是并发安全问题，不是线程安全语法糖
- 别对纯值类型（如
int、string）加读写锁 —— 值拷贝本身是安全的，锁反而拖慢性能 -
RWMutex不递归：同一个 goroutine 重复调用RUnlock()会 panic，Unlock()同理
ReadLock 和 WriteLock 的调用顺序和配对规则
RWMutex.RLock() 和 RWMutex.RUnlock() 必须成对出现，且只能在持有读锁的 goroutine 内调用 RUnlock()；RLock() 可以被多个 goroutine 同时调用，但一旦有 goroutine 调用了 Lock()，所有新的 RLock() 会被阻塞，直到写锁释放。
- 写锁优先级高于读锁：只要有人在等
Lock()，新来的RLock()就得排队 —— 这能防饿死，但也可能让读请求堆积 - 不能在持有读锁时调用
Lock()（会死锁），也不能在持有写锁时调用RLock()（虽然语法允许，但逻辑错乱） - 推荐用
defer mu.RUnlock()或defer mu.Unlock()，避免忘记解锁导致整个程序卡住
常见 panic：“sync: RUnlock of unlocked RWMutex” 怎么定位
这个错误通常不是“没加锁”，而是“多解了一次锁”或“在没加锁的上下文中调用了 RUnlock()”。比如把 defer mu.RUnlock() 放在了 if 分支外，但实际只在某个分支里调用了 RLock()。
立即学习“go语言免费学习笔记（深入）”；
- 检查所有
RUnlock()是否严格对应一次RLock()，尤其注意 error early return 路径 - 不要在循环体里反复
RLock()/RUnlock()—— 锁粒度太细，容易漏配对，也影响性能 - 用
go build -race编译运行，race detector 能捕获大部分解锁不匹配和数据竞争 - 示例错例：
mu.RLock() if cond { return // 忘了 RUnlock！ } doWork() mu.RUnlock()
嵌入 RWMutex 到结构体时的零值陷阱
sync.RWMutex 是可直接使用的零值类型，不需要显式初始化；但如果你把它作为结构体字段嵌入，并用指针接收方法操作它，要注意 receiver 是值还是指针。
- 如果方法签名是
func (s MyStruct) Read() {...}，那s.mu.RLock()操作的是mu的副本 —— 完全无效，不提供任何保护 - 必须用指针接收器：
func (s *MyStruct) Read() {...}，否则锁根本不起作用 - 字段名建议用
mu或rwmu，避免和业务字段混淆；别叫lock，容易误以为是sync.Mutex - 嵌入时不用
sync.RWMutex匿名字段（如sync.RWMutex），除非你真需要透出全部方法 —— 易误用Lock()/Unlock()混淆语义
真正难的不是怎么写那几行 RLock()，而是判断哪些字段该被锁、锁到哪一层、读写边界是否清晰。一个 map 加了 RWMutex，不代表所有访问都安全 —— 如果你把 map 里的指针对象拿出来又并发修改，锁就失效了。
