Go的sync包用于解决并发访问共享资源时的数据竞争问题，关键在于识别需保护的共享变量读写场景。使用sync.Mutex可串行化临界区操作，需确保所有读写路径均加锁并用defer释放；避免复制Mutex和在锁内执行耗时操作。对于读多写少场景，sync.RWMutex允许多个读但写时独占，注意读饥饿与锁升级死锁风险。sync.Once保证初始化函数仅执行一次，适用于懒加载全局资源，内部无锁优化且性能佳，但需处理panic。sync.WaitGroup用于协调goroutine生命周期，通过Add、Done和Wait匹配实现批量任务等待，不可在goroutine中调用Wait以防死锁。合理选择sync原语，优先通过channel传递数据，无法避免共享内存时再使用sync工具。
在 Go 中，sync 包是控制并发安全的核心工具，它不负责启动 goroutine，而是解决多个 goroutine 同时访问共享资源时的数据竞争问题。关键不是“用不用 sync”，而是“哪些地方必须用”——只要存在读写共享变量（尤其是写），且没有其他同步机制（如 channel 串行化），就该考虑 sync 原语。
用 sync.Mutex 保护临界区
sync.Mutex 是最常用的互斥锁，适用于需要串行访问某块内存的场景。注意：锁的是“操作”，不是“变量”；要确保所有读写该资源的代码路径都加锁，漏掉任意一处都会导致竞态。
- 习惯性用
defer mu.Unlock()配合mu.Lock()，避免忘记释放 - 不要复制已使用的 Mutex（Go 1.19+ 会 panic），应传指针或作为结构体字段
- 避免锁内做耗时操作（如 HTTP 请求、大循环），否则会阻塞其他 goroutine
用 sync.RWMutex 区分读写场景
当读多写少（比如配置缓存、状态映射表），sync.RWMutex 能显著提升吞吐量：多个 goroutine 可同时读，但写时会独占，且阻塞新读请求。
- 读操作用
RLock()/RUnlock()，写操作仍用Lock()/Unlock() - 注意：写锁优先级高于读锁，持续写入可能导致读饥饿，必要时需配合限流或降级
- 不能在持有 RLock 时升级为 Lock（会死锁），需先释放再重锁
用 sync.Once 确保初始化只执行一次
sync.Once 是轻量、线程安全的单次执行机制，常用于懒加载全局资源（如数据库连接池、配置解析器）。
立即学习“go语言免费学习笔记（深入）”；
- 只需定义
var once sync.Once，然后once.Do(func(){...}) - 即使多个 goroutine 同时调用
Do，函数也仅执行一次，且后续调用直接返回 - 内部无锁优化，性能好；但注意：Do 中 panic 会导致后续调用 panic，需自行 recover
用 sync.WaitGroup 协调 goroutine 生命周期
sync.WaitGroup 不用于保护数据，而是等待一组 goroutine 完成。适合批量任务收尾、服务关闭等待等场景。
- 提前调用
wg.Add(n)（建议在 goroutine 启动前），再启 n 个 goroutine，每个末尾调wg.Done() - 避免 Add 和 Done 数量不匹配（常见于循环中漏 Add 或异常提前 return 导致 Done 缺失）
- 主线程用
wg.Wait()阻塞等待，不要在 goroutine 里 Wait，易死锁
基本上就这些。sync 不是银弹，也不是越用越好——过度加锁会拖慢性能，不用又容易出 bug。关键是理解共享状态在哪、谁在读写、是否必须同时发生。多数情况下，优先用 channel 显式传递数据，实在绕不开共享内存时，再选合适的 sync 原语。
