sync.RWMutex适用于读多写少场景，允许多读单写，但禁止锁升级；误用会导致死锁或panic，且不适用于高频写或重读操作。
sync.RWMutex 的基本读写分离逻辑
读多写少场景下，sync.RWMutex 能显著提升并发读性能，因为它允许多个 goroutine 同时读，但写操作会独占锁（阻塞所有读和写）。关键点在于：读锁不互斥，写锁互斥且排斥所有读锁。
常见误用是把 RLock/RUnlock 和 Lock/Unlock 混用在同一个临界区，比如用 RLock 进入后又调用 Lock ——这会导致死锁，因为 RWMutex 不支持升级锁。
- 只读操作必须用
RLock+RUnlock - 写操作或读+写混合操作必须用
Lock+Unlock - 不能在一个 goroutine 中先
RLock再Lock，也不能跨 goroutine 传递锁状态
何时该用 RWMutex 而不是 Mutex
不是所有共享数据都适合 RWMutex。它只有在读操作远多于写操作、且单次读耗时较短时才体现优势。如果读操作本身很重（比如遍历大 map 并做复杂计算），或者写操作频繁（写占比 >10%），RWMutex 可能因内部调度开销反而不如 sync.Mutex。
典型适用场景：map[string]*Config 类型的只读配置缓存、状态快照生成、统计计数器聚合。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免对小对象（如单个
int64）用RWMutex—— 锁开销可能超过收益 - 若写操作需基于当前读结果做判断（如“如果 key 不存在则写入”），必须用
Lock，不能靠两次RLock+ 条件写来规避 -
RWMutex不保证写操作的 FIFO，饥饿情况可能发生（大量读持续到来时，写可能被延迟）
常见 panic 和死锁陷阱
最常触发 panic 的是未配对的 RUnlock 或 Unlock，尤其是从函数返回路径遗漏解锁。Go 的 sync.RWMutex 在已解锁状态下再调用 Unlock 或 RUnlock 会直接 panic：sync: RUnlock of unlocked RWMutex。
另一个隐蔽问题是 defer 放错位置。例如在循环内 defer RUnlock，会导致第一次迭代后就释放锁，后续迭代实际无锁保护。
- 务必确保每个
RLock都有且仅有一个对应的RUnlock，Lock同理 - 推荐写法：
defer mu.RUnlock()紧跟mu.RLock()后，不要跨多层 if 或提前 return - 测试时可用
-race检测竞态，但它无法捕获锁使用逻辑错误（如漏 unlock），需靠代码审查或静态检查工具（如go vet -locks）辅助
与 atomic.Value 的对比选择
如果共享数据是不可变结构（比如整个 map 替换而非单 key 更新），atomic.Value 往往比 RWMutex 更轻量、无锁、且无死锁风险。它适用于“读多、写少、写即全量替换”的模式。
但 atomic.Value 不能做条件更新（如 CAS）、不支持部分修改、且类型擦除带来运行时类型断言开销。一旦开始用 RWMutex 做细粒度控制（如并发增删 map 中不同 key），就无法退回到 atomic.Value。
- 配置热更新、只读视图导出 → 优先考虑
atomic.Value - 需要原地修改字段、依赖读结果做写决策、或写操作分散 → 必须用
RWMutex（或更细粒度的分段锁） -
atomic.Value.Store是全量替换，若新值构造成本高，应避免在高频写路径中反复分配
真正难的是权衡读写比例、数据结构生命周期和一致性要求——这些没法靠一个锁类型自动解决，得看具体访问模式是否匹配其设计假设。
