sync标准库通过Mutex、RWMutex、WaitGroup、Once、Map等工具解决并发读写共享变量的数据竞争问题，核心是保证操作原子性与临界区安全。
sync 标准库解决的是多个 goroutine 同时读写共享变量时的数据竞争（data race）问题——不加同步，结果就不可信，程序可能崩溃、返回错误值、甚至静默损坏数据。
为什么普通变量在并发下会出错？
Go 的原生类型（如 int、map、结构体字段）不是并发安全的。两个 goroutine 同时执行 counter++，底层是“读→改→写”三步，中间可能被抢占，导致一次更新丢失。运行时加 -race 标志能立刻暴露这类问题。
- 常见错误现象：
fatal error: concurrent map writes（对普通map并发写）、计数器最终值远小于预期、配置加载重复或缺失 - 根本原因：CPU 指令重排 + 缓存不一致 + goroutine 调度不可控，使得非原子操作无法保证中间态隔离
- 不是“偶尔出错”，而是“只要条件凑齐，必现”——只是高并发下更容易触发
sync.Mutex 和 sync.RWMutex 怎么选？
sync.Mutex 是最基础的互斥锁，所有访问（读/写）都串行；sync.RWMutex 则区分读写：允许多个 goroutine 同时读，但写时独占、且阻塞新读请求——适合读多写少场景（比如配置缓存、状态快照）。
- 用
RWMutex时注意写饥饿：如果写操作频繁，读请求可能长期等待，甚至饿死 - 别在锁内做耗时操作（如 HTTP 调用、数据库查询），否则整个临界区被拖慢，其他 goroutine 集体卡住
- 必须成对使用：
Lock()/Unlock()或RLock()/RUnlock()，推荐用defer保证释放 - 不要复制已使用的 mutex 实例，Go 运行时会检测并 panic
sync.WaitGroup 是怎么安全关闭 channel 的？
很多代码试图靠“计数器减到 0”来关 channel，但没等所有 goroutine 真正退出就关了，导致发送 panic 或数据丢失。sync.WaitGroup 把“任务启动”和“任务完成”两个动作解耦，确保 channel 只在最后一个 goroutine 离开前关闭。
立即学习“go语言免费学习笔记（深入）”；
- 主协程调用
wg.Add(n)声明要等 n 个任务 - 每个子 goroutine 执行完后调用
wg.Done()（通常 defer） - 主协程在
wg.Wait()返回后，才调用close(ch)—— 此时可 100% 确保无 goroutine 再向该 channel 发送 - 切忌在子 goroutine 中调用
wg.Wait()，那会导致死锁
sync.Once 和 sync.Map 适合什么场景？
sync.Once 不是锁，是“只跑一次”的保障机制，内部用原子操作实现，无锁且高效；sync.Map 则是专为高并发读多写少设计的 map，避免了手动加锁的繁琐，但牺牲了遍历和删除的灵活性。
-
sync.Once.Do()内部 panic 会导致后续所有调用 panic，必须在函数体内 recover -
sync.Map的Range()不保证原子性，遍历时可能漏掉刚写入的 key；它不适合高频写或需要按顺序遍历的场景 - 如果写操作较多，或者需要支持复杂操作（如 CAS 更新、批量删除），还是老实用
sync.RWMutex + map - 不要把
sync.Map当作“银弹”，它的优势只在特定负载模式下成立
真正难的从来不是记住 API，而是在读写路径分散、生命周期嵌套、panic 可能中断执行的现实里，让每处加锁/等待/初始化都严丝合缝——漏掉一个 defer Unlock()，或早关一秒 channel，就足以让线上服务行为飘忽不定。
