必须用sync.Mutex当多个goroutine直接读写同一跨请求变量（如缓存map、计数器），且未用channel传递所有权；只写加锁而读裸奔会导致concurrent map read/write panic。
微服务里用 sync 包保护数据，不是“加了锁就安全”，而是得看共享状态在哪、谁在读写、频率如何——多数时候，sync.Mutex 足够，但乱套用反而引入死锁或性能瓶颈。
什么时候必须用 sync.Mutex？
当多个 goroutine 直接读写同一个变量（比如全局配置缓存、连接池计数器、本地限流令牌桶），且该变量生命周期跨请求、跨 goroutine 时，sync.Mutex 是最直接有效的防护。
- 典型场景：服务启动后初始化一个
map[string]*Client缓存 HTTP 客户端，后续所有请求 goroutine 都会查它、偶尔增删 —— 必须加锁 - 常见错误：只对写操作加锁，读操作裸奔 → 出现
fatal error: concurrent map read and map write - 参数差异：
Lock()和Unlock()必须成对出现；用defer mu.Unlock()是底线，但不能掩盖逻辑错误（比如在锁内调用可能阻塞的函数） - 性能影响：高并发下频繁争抢同一把锁，会导致 goroutine 大量自旋或休眠，
pprof里能看到sync.(*Mutex).Lock占用显著 CPU 时间
sync.RWMutex 真的比 sync.Mutex 快吗？
只在读远多于写的场景下才快。微服务中常见的“配置热更新”“路由表缓存”“指标聚合器”适合它；但若写操作每秒几次以上，RWMutex 的写锁开销（需唤醒所有读锁等待者）可能反超普通 Mutex。
- 使用陷阱：误把
RUnlock()写成Unlock()→ panic：sync: RUnlock of unlocked RWMutex - 读锁不阻塞读，但会阻塞写；写锁则阻塞所有读和写 —— 如果你有个长耗时的
UpdateConfig()，所有并发请求都会卡住 - 注意：不能嵌套使用读锁和写锁（比如在
RLock()区域里再调Lock()），会死锁
为什么 sync.Once 在微服务初始化里不可替代？
它解决的是“只执行一次”的语义问题，不是线程安全的替代品。比如注册 Prometheus 指标、加载证书、初始化 gRPC 连接池 —— 这些操作本身不能重复，且可能被多个 goroutine 并发触发。
立即学习“go语言免费学习笔记（深入）”；
- 关键点：
sync.Once.Do()内部已保证原子性，外部无需再加锁 - 容易踩的坑：传给
Do()的函数如果 panic，Once会标记为“已完成”，后续调用直接返回，不会重试 —— 所以初始化逻辑里要自己处理错误，别让它 panic - 不要用它替代
sync.Mutex：比如想“每个请求只初始化一次某结构体”，那是错的 ——Once是全局单次，不是 per-request
别忘了 sync.WaitGroup 不是锁，但它影响数据安全
它本身不保护数据，但常和锁一起用在“等待资源就绪”场景。比如微服务启动时，要等配置加载、DB 连接池建立、gRPC server 启动完成，才能对外提供服务。
- 典型误用：在 goroutine 里忘记调
wg.Done()→ 主 goroutine 永远Wait()不返回，服务起不来 - 更隐蔽的问题：在加锁区域调
wg.Add(1)，但wg.Done()在锁外执行 → 可能导致 WaitGroup 计数器被并发修改，panic：sync: negative WaitGroup counter - 建议：所有
wg.Add()放在 goroutine 启动前（即主线程中），wg.Done()放在 goroutine 最末尾，且不依赖锁状态
真正麻烦的从来不是“怎么加锁”，而是判断“哪里需要锁”——微服务里大量共享状态其实是隐式的（比如 struct 字段、包级变量、甚至 logger 实例的内部 buffer），一旦漏判，race detector 可能只在压测时才暴露问题。
