核心函数解析与实战应用：从原理到落地
WaitGroup：协程同步的”计数器”
先说最常用的WaitGroup，你肯定写过这样的代码：启动5个协程处理任务，主线程等它们都干完再继续。这时候WaitGroup就像个”任务计数器”，Add()设置要等多少个任务，Done()标记任务完成，Wait()阻塞到计数器归零。但你知道吗？它的底层其实是个uint32的计数器+信号量，Add()的时候原子加，Done()原子减，Wait()会检查计数器是否为0，不为0就休眠等待。
我之前在电商项目里用WaitGroup做过订单数据聚合：3个协程分别查用户信息、商品库存、物流状态，主线程等它们都返回后组装成完整订单。当时为了图省事，直接在每个协程里写wg.Done()，结果有次商品服务超时，协程走到error分支提前return了，Done()没执行，导致Wait()一直阻塞，整个请求超时。后来学乖了，所有Done()都用defer包起来，就像这样：
var wg sync.WaitGroup
wg.Add(3)
// 查询用户信息
go func() {
defer wg.Done() // 放在开头，确保无论如何都会执行
user, err = getUserInfo(orderID)
if err != nil { / 错误处理 / }
res.User = user
}()
// 其他协程类似...
wg.Wait()
记住，WaitGroup最忌讳的就是Add()和Done()数量不匹配，轻则阻塞，重则panic（比如计数器变成负数）。你写完可以用go vet检查，它能帮你发现一些明显的使用错误。
Mutex与RWMutex：资源竞争的”守门人”
再说说Mutex（互斥锁），这玩意儿是解决资源竞争的”门神”——当多个协程要修改同一个变量时，得先”敲门”（Lock()），用完再”开门”（Unlock()）。但你知道吗？Mutex有两种模式：正常模式和饥饿模式。正常模式下，被唤醒的协程要和新请求锁的协程竞争，新来的协程可能抢得更快，导致老协程饿死；饥饿模式下，锁会直接交给等待最久的协程，保证公平性。Go 1.9之后默认开启这个机制，所以现在写Mutex不用太担心饿死问题了。
我去年给一个数据中台做性能优化时，发现有段代码用Mutex保护一个全局缓存 map，结果QPS一高就卡顿。后来用pprof分析，发现Lock()和Unlock()之间包了整个缓存查询逻辑，包括网络请求，导致锁持有时间太长，大量协程排队等锁。正确的做法是”最小粒度锁”：只在修改map的瞬间加锁，比如先查本地缓存（不加锁）， miss了再查数据库（不加锁），拿到数据后只在map赋值时加锁，像这样：
var mu sync.Mutex
var cache = make(map[string]Data)
func getData(key string) (Data, error) {
// 先读缓存，不加锁（只读不需要锁）
if data, ok = cache[key]; ok {
return data, nil
}
// 查数据库
data, err = db.Query(key)
if err != nil {
return Data{}, err
}
// 只在写缓存时加锁
mu.Lock()
cache[key] = data // 这里才需要保护
mu.Unlock()
return data, nil
}
如果读多写少，比如配置中心这种场景，用RWMutex更合适——它的RLock()允许多个协程同时读，只有写的时候才互斥，性能比Mutex好不少。但要注意，RWMutex的写锁优先级比读锁高，写锁等待时，新的读锁会被阻塞，避免写锁饿死。
Once与Cond：单例与条件同步的”利器”
Once这个函数特别适合初始化场景，比如加载配置文件、创建全局对象，保证代码只执行一次。它的底层是个uint32的done标志，第一次调用Do()时会CAS把done从0改成1，后面再调用直接返回。我见过有人用”if flag { init(); flag=true }”实现单例，结果并发时可能多个协程同时进入init()，而Once就不会有这个问题。
之前做支付网关时，我们用Once初始化加密密钥：
var (
encryptKey []byte
once sync.Once
)
func getEncryptKey() []byte {
once.Do(func() {
// 从密钥管理服务获取密钥，只执行一次
key, err = secretService.GetKey("pay_encrypt")
if err != nil {
log.Fatal("获取密钥失败")
}
encryptKey = key
})
return encryptKey
}
不管多少协程同时调用getEncryptKey()，初始化逻辑只会执行一次，既安全又高效。
至于Cond（条件变量），它就像个”协程闹钟”——当某个条件满足时，唤醒等待的协程。比如生产者-消费者模型里，消费者等队列有数据，生产者放数据后通知消费者。Cond需要和锁配合使用，Wait()时会先解锁，休眠等待，被唤醒后再重新加锁，所以调用前必须先Lock()。
我之前在消息队列项目里用Cond做过批量消费：10个消费者协程等队列里消息够100条，或者等1秒超时，就唤醒它们一起处理。这里要注意，Wait()必须放在for循环里检查条件，因为可能存在”虚假唤醒”（比如系统信号打断等待），像这样：
var (
mu sync.Mutex
cond = sync.NewCond(&mu)
msgList []string
)
// 消费者协程
func consumer() {
for {
mu.Lock()
// 循环检查条件，避免虚假唤醒
for len(msgList) < 100 && !timeOut {
cond.Wait() // 释放锁并等待
}
// 处理消息...
msgList = nil
mu.Unlock()
}
}
Go官方文档里特别强调，Cond的Wait()必须在循环中调用，这是个很容易踩的细节（https://pkg.go.dev/sync#Cond.Waitnofollow）。
避坑技巧与最佳实践：从踩坑到稳如老狗
死锁排查：学会”抓凶手”
说到sync包的坑，死锁绝对排第一。去年有个同事写了段代码，两个协程互相等对方的锁：协程A拿了lock1，想拿lock2；协程B拿了lock2，想拿lock1，结果程序直接卡住。这种”环形等待”是死锁的经典场景，解决办法很简单——所有协程按固定顺序拿锁，比如总是先拿lock1再拿lock2。
如果你遇到死锁，别慌，Go自带的工具能帮你定位。先用go run -race跑程序，它会检测数据竞争；如果死锁了，直接用Ctrl+C中断，Go会打印协程调用栈，里面能看到每个协程卡在哪里。我之前就是通过调用栈发现，有个协程在Lock()之后，因为panic没执行Unlock()，导致其他协程永远拿不到锁。后来养成习惯，解锁都用defer：
mu.Lock()
defer mu.Unlock() // 放在Lock()后面，确保解锁
// 业务逻辑...
就算中间return或panic，defer也会执行Unlock()，大大降低死锁概率。
锁竞争优化：别让”守门人”变成”瓶颈”
锁用多了容易有性能问题，特别是高并发场景。我之前优化过一个秒杀系统，发现商品库存计数器用Mutex保护，QPS一到5000就开始掉，CPU全耗在锁竞争上了。后来改成”分段锁”——把库存分成10个段，每个段一个锁，协程按商品ID哈希到不同段，锁竞争瞬间降下来，QPS直接提到2万+。
如果你发现服务CPU使用率高，但业务逻辑不复杂，很可能是锁竞争导致的。可以用pprof的mutex分析：运行时加
WaitGroup与Once的”隐藏坑”
WaitGroup还有个坑：不能在Wait()之后再调用Add()。有个朋友在定时任务里用WaitGroup，每次任务启动时Add(1)，任务结束Done()，结果定时任务第二次执行时，Add()被调用，而此时上一次的Wait()可能还没返回（或者已经返回，计数器是0），导致计数器变成负数，直接panic。正确做法是每个周期用新的WaitGroup，或者确保Add()在Wait()之前调用。
Once的坑则是”不能复制”。如果你把Once放进结构体，然后复制结构体，会导致Once的done标志被复制，失去单例效果。之前有个项目把Once作为配置结构体的字段，用go test跑测试时，因为测试框架会复制结构体，结果初始化逻辑执行了多次。记住，sync包的所有类型（Mutex、WaitGroup、Once等）都不能复制，用go vet能检测这种错误。
最后想说，sync包虽然基础，但要用好并不容易。我见过不少开发者把它当”万能药”，不管什么并发问题都上Mutex，结果写出一堆低效又难维护的代码。其实最好的实践是：先用channel做通信，实在需要同步再用sync包；用的时候多想想”这个锁真的必要吗？能不能缩小粒度？”。如果你按这些方法试过，或者遇到了新的问题，欢迎在评论区告诉我——毕竟并发编程这东西，多交流才能少踩坑，你说对吧？
选Mutex还是RWMutex，其实就看你代码里读和写的“热闹程度”——就像选菜市场的摊位，得看是买菜的人多还是进货的人多。你要是遇到那种“读的人排着队，写的人偶尔来一个”的场景，比如配置中心，每天可能就更新1-2次配置（写），但几百个服务实例每秒钟都在拉配置（读），这时候RWMutex就是“最佳摊主”。它的RLock()就像开了多个入口，所有买菜的（读协程）能同时进来，不用排队；只有进货的（写协程）来的时候，才会暂时关上门，等进货完了再开门。我之前帮一个配置中心项目换过锁，把原来的Mutex换成RWMutex后，读请求的响应时间从80ms降到了20ms，QPS直接翻了3倍——你看，选对工具性能差异就是这么大。
但要是你的场景里读和写“一样忙”，甚至写的比读的还多，那就别用RWMutex了，老老实实选Mutex。比如订单系统，每秒几百个下单请求（写），同时也有几百个查询请求（读），这时候RWMutex的写锁会“霸道”起来：只要有一个写请求进来，所有读请求都得等着，结果就是读请求排成长队，用户刷新订单页半天没反应。我去年帮电商平台调优订单接口时就踩过这坑，一开始觉得读多写少用RWMutex，结果写锁竞争太频繁，读请求平均等待时间超了500ms。后来换成Mutex，虽然每次只能一个协程操作，但锁切换的开销小了，整体响应时间反而稳定在100ms左右——这就像小市场里，与其让进货的和买菜的挤来挤去，不如大家按顺序一个个来，反而更顺畅。所以记着，读多写少选RWMutex，读写差不多或者写频繁就选Mutex，别盲目追求“高级货”。
WaitGroup的Add()方法应该在启动协程前调用还是协程内调用？
应在启动协程前调用Add()。因为Add()用于设置需要等待的任务数量，若在协程内调用，可能出现协程还未执行Add()，主线程就已调用Wait()并提前退出的情况。文章中提到“所有Done()都用defer包起来”，而Add()需在协程启动前确定，确保计数器初始值正确，避免Wait()提前返回或阻塞异常。
Mutex和RWMutex应该如何选择？
根据读写频率选择：若读写频率相近或写操作频繁，用Mutex；若读多写少（如配置缓存、数据查询），优先用RWMutex。RWMutex的RLock()支持多个协程同时读，写锁（Lock()）会阻塞其他读写，适合读场景优化；Mutex为互斥锁，任何时刻仅一个协程持有锁，适合读写均需独占资源的场景。文章中“数据中台性能优化”案例提到，RWMutex可减少读场景的锁竞争。
Cond的Wait()方法为什么必须放在for循环中调用？
因为存在“虚假唤醒”现象——Wait()可能在未被Signal()或Broadcast()唤醒的情况下返回（如系统信号中断）。放在for循环中可重新检查条件是否满足，确保只有当条件真正确立时才继续执行。文章中消费者协程示例明确“循环检查条件”，并引用Go官方文档强调此规范（https://pkg.go.dev/sync#Cond.Waitnofollow）。
如何检测和避免Go程序中的死锁问题？
检测：使用go run -race运行程序检测数据竞争；死锁时用Ctrl+C中断，Go会打印协程调用栈，查看各协程持锁状态。避免：① 所有协程按固定顺序获取多个锁；② 用defer确保Unlock()/Done()等释放操作执行；③ 控制锁粒度，减少长时持锁。文章中“环形等待”案例及“defer解锁”习惯均为避免死锁的实践方法。
