sync.mutex 必须手动 unlock，因无自动释放机制，漏掉会导致永久阻塞；waitgroup.add 不能使计数为负，否则 wait 永不返回；once.do 保证初始化仅执行一次且安全；rwmutex 仅在读远多于写时有益。
sync.Mutex 为什么加锁后还要记得 unlock
因为 Mutex 不是作用域绑定的，它不会自动释放——Go 没有析构函数或 defer 自动注入机制来兜底。漏掉 Unlock() 会导致后续 goroutine 永久阻塞，且这种死锁往往只在高并发或特定时序下暴露。
- 常见错误现象：
fatal error: all goroutines are asleep - deadlock，但堆栈里可能只显示某个 goroutine 卡在mu.Lock() - 使用场景：保护共享变量读写（如计数器、map、缓存结构），尤其当写操作非原子时必须成对出现
- 实操建议：优先用
defer mu.Unlock()放在Lock()后紧邻行，哪怕中间有 return 或 panic；避免在 if 分支里条件性调用Unlock() - 参数差异：无参数；
TryLock()是非阻塞变体，返回 bool，适合需要快速失败的路径（比如限流判断）
sync.WaitGroup 的 Add 值为什么不能为负
WaitGroup 内部用 int64 计数，但 Add(-1) 本身合法，问题在于它会让计数器变成负数，而 Wait() 只在计数为 0 时返回——负数永远不会触发唤醒，导致永久等待。
- 常见错误现象：goroutine 卡在
wg.Wait()，pprof 显示其处于 sync.runtime_SemacquireMutex 状态 - 使用场景：协调多个 goroutine 完成后再继续主流程，典型如批量 HTTP 请求、并行数据处理
- 实操建议：所有
Add()必须在go启动前调用；不要在 goroutine 内部调用Add()（除非你明确控制了竞态）；更安全的做法是启动前wg.Add(len(tasks)) - 性能影响：
WaitGroup是轻量级，但频繁Add/Done在极端高并发下会有原子操作开销；若需高频增减，考虑用sync.Pool配合重用
sync.Once.Do 为什么适合单例初始化
因为 Once 内部用一个 uint32 标志位 + 原子操作实现“仅一次”，且能保证初始化函数执行完成前，所有其他调用者会阻塞等待，而不是重复执行或拿到未完成的中间状态。
- 常见错误现象：单例对象被多次初始化（比如数据库连接池重复创建）、或初始化函数 panic 后后续调用直接返回而不重试（这是设计行为，不是 bug）
- 使用场景：全局配置加载、第三方客户端实例化、昂贵资源的一次性准备
- 实操建议：把初始化逻辑封装进闭包或独立函数，传给
once.Do()；不要在Do函数里做可能 panic 且不可恢复的操作，否则该Once实例永久失效 - 兼容性注意：Go 1.21+ 对
Once做了微优化，但语义完全一致；旧版本也无需担心，它很早就稳定了
sync.RWMutex 读多写少时才值得用
RWMutex 的读锁允许多个 goroutine 并发进入，但写锁仍独占；它的优势只在读操作远多于写操作时成立。如果读写比例接近，或者读操作本身很短，那么额外的锁状态管理反而比普通 Mutex 更慢。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：用了
RWMutex却没观察到性能提升，甚至更差；误以为RLock()完全无代价（其实也有原子操作和调度开销） - 使用场景：缓存读取、配置快照访问、日志级别开关检查等低延迟、高频率只读路径
- 实操建议：写操作必须用
Lock()/Unlock()，读操作用RLock()/RUnlock()；禁止在持有读锁时尝试升级为写锁（会死锁） - 参数差异：无参数；
RLocker()返回一个只读接口，方便传递给不信任写权限的函数
实际写业务时，最容易忽略的是 WaitGroup 的调用时机和 Once 对 panic 的零容忍——它们不像 Mutex 那样有明显报错，而是让程序悄悄卡住或跳过初始化。
