Go sync包提供底层同步原语，误用易致死锁、竞态或性能退化；应依场景选Mutex/RWMutex，慎用Once.Do，WaitGroup.Add须在goroutine启动前调用，Pool仅适用于GC可控的临时对象复用。
Go 的 sync 包不是用来“加锁就完事”的，它提供的是底层同步原语，用错场景或组合方式反而会引发死锁、竞态或性能退化。
什么时候该用 sync.Mutex 而不是 sync.RWMutex
读多写少且读操作耗时明显时，RWMutex 才有收益；否则直接用 Mutex 更轻量、更安全。
-
RWMutex的RLock/RUnlock在高并发读下可能饿写，尤其当持续有新读请求进来时，写操作可能无限期等待 - 如果读操作只是取一个
int或bool字段，用RWMutex反而增加调度开销，Mutex更合适 -
RWMutex不支持递归读锁：同一个 goroutine 多次RLock后只调一次RUnlock会导致 panic
sync.Once 的常见误用：以为它能控制「多次执行」，其实它只保「至少一次」
Once.Do 保证函数最多执行一次，但不保证执行成功 —— 如果传入的函数 panic，Once 会记录为“已执行”，后续调用直接返回，不会重试。
- 不要把带错误处理逻辑（比如重试、fallback）的代码塞进
Once.Do，应在外层封装 - 初始化失败需暴露状态时，建议搭配
sync.Once+ 显式标志位：var once sync.Once var initErr error var inited bool func initResource() error { once.Do(func() { initErr = doActualInit() inited = initErr == nil }) return initErr }
sync.WaitGroup 的 Add 必须在 goroutine 启动前调用
这是最常踩的坑：WaitGroup.Add(1) 放在 go func() 内部，会导致 Wait() 永远阻塞，因为 Add 和 Done 不在同一线程可见序列中。
- 正确姿势是：先
wg.Add(1)，再go func() { defer wg.Done(); ... }() - 若需动态确定 goroutine 数量，用循环前预设总数，不要在循环体内边启 goroutine 边 Add
- 注意
WaitGroup不能被复制 —— 如果结构体里嵌了sync.WaitGroup，别用值传递，必须传指针
sync.Pool 不是通用缓存，它的生命周期由 GC 控制
Pool 中的对象可能在任意 GC 周期被清理，且不同 goroutine 获取到的可能是不同批次的对象。它只适合「高频创建销毁 + 对象可复用 + 无强状态依赖」的场景，比如临时字节切片、JSON 解析器实例。
- 不要往
Pool里放含闭包、channel 或未关闭文件句柄的对象 -
New函数仅在 Pool 空时触发，不保证每次 Get 都调用；对象放回 Pool 前务必清空敏感字段（如用户 ID、token），否则可能泄露 - 测试时禁用 GC（
GODEBUG=gctrace=1）可观察 Pool 实际复用率，比盲目使用更可靠
真正难的不是记住每个类型的签名，而是判断「当前问题是否属于 sync 包该解决的范畴」—— 很多时候，用 chan 配合 select 或重构为无共享设计，比加锁更简洁、更符合 Go 的并发哲学。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
