应优先用 atomic、channel、sync.Pool 替代 mutex+cond；缩小临界区，只锁共享数据；读多写少用 sync.RWMutex；cond.Wait 必须 for 循环检查；用 channel+select+context 替代无超时 cond 等待。
用无锁数据结构替代简单同步场景
很多情况下，开发者习惯性地用 mutex + cond 实现生产者-消费者或状态等待逻辑，但 Go 标准库已提供更轻量的替代方案。比如：
– 状态轮询 + atomic：对布尔标志、计数器等简单状态，用 atomic.LoadUint32 / atomic.StoreUint32 替代互斥锁读写，避免锁进入内核态；
– 通道（channel）天然支持阻塞等待：用带缓冲的 channel 做任务队列，比手写条件变量 + mutex 更简洁、更少出错；
– sync.Pool 复用对象：减少 GC 压力间接降低锁竞争（如频繁创建/销毁带锁结构体）。
缩小临界区，只锁真正共享的部分
常见误区是把整个函数逻辑包进 mu.Lock() —— 实际上应只保护“多 goroutine 同时访问且可修改”的那几行。例如：
❌ 错误写法：
mu.Lock()
data = processData(input) // 耗时计算，不涉及共享数据
sharedMap[key] = data // 只这行需要保护
mu.Unlock()
✅ 正确做法：
data = processData(input) // 提前算好
mu.Lock()
sharedMap[key] = data // 仅写入时加锁
mu.Unlock()
同样，读多写少场景优先考虑 sync.RWMutex，读操作用 RLock()，避免读之间互相阻塞。
避免条件变量的虚假唤醒与忙等陷阱
cond.Wait() 必须配合 for 循环检查条件，因为可能被信号中断或虚假唤醒。直接 if 判断极易出错：
❌ 危险写法：
mu.Lock()
if !ready {
cond.Wait()
}
doWork()
mu.Unlock()
✅ 正确模式：
mu.Lock()
for !ready {
cond.Wait()
}
doWork()
mu.Unlock()
另外，避免在循环中频繁调用 cond.Signal() 或 cond.Broadcast() —— 若通知逻辑本身可合并（如批量完成），改用一次通知 + 状态标记，减少唤醒开销。
立即学习“go语言免费学习笔记（深入）”；
用 context 控制等待生命周期，防止死锁和资源滞留
条件变量等待若无超时或取消机制，容易卡死。推荐用 sync.Cond 配合 runtime.Gosched() 或更稳妥地，改用 channel + select 支持 context：
select {
case <-doneCh:
// 工作完成
case <-ctx.Done():
// 超时或取消，清理后退出
}
这种方式无需显式锁，调度更可控，也利于测试和中断传播。Go 1.22+ 中 sync.Cond 已支持 WaitUntil，但 channel + context 仍是主流推荐路径。
基本上就这些。锁不是不能用，关键是别让它成为瓶颈——多数性能问题不在锁本身，而在锁的范围、频率和等待逻辑设计上。
