高频写场景下sync.Mutex易成瓶颈，应按字段拆分锁或用atomic；WaitGroup Add()须启动前调用；sync.Map仅适用于读多写少；channel同步性能远低于Mutex，仅适用于跨goroutine通信等特定场景。
sync.Mutex 在高频写场景下成为瓶颈
当多个 goroutine 频繁更新同一结构体字段（比如计数器、状态标志），只用 sync.Mutex 保护整个结构，会强制串行化所有写操作，哪怕字段彼此无关。实测中，100 个 goroutine 并发写两个独立字段，吞吐量可能比无锁下降 80% 以上。
更合理的方式是按字段或逻辑域拆分锁：
- 用
sync.RWMutex替代sync.Mutex，读多写少时显著提升并发读性能 - 对结构体中不共享的字段，改用独立的
sync.Mutex或sync.Atomic类型（如int64计数器优先用atomic.AddInt64） - 避免在锁内做 IO、网络调用、长耗时计算——这些会把锁持有时间拉长，放大争用
sync.WaitGroup 误用导致 goroutine 泄漏
sync.WaitGroup 的 Add() 必须在 Go 启动前调用，否则存在竞态：goroutine 可能在 Wait() 返回后才执行 Done()，造成永久阻塞或 panic（panic: sync: negative WaitGroup counter）。
正确模式只有两种：
立即学习“go语言免费学习笔记（深入）”；
- 启动前明确数量：
wg.Add(len(tasks))<br>for _, t := range tasks {<br> go func(task Task) {<br> defer wg.Done()<br> process(task)<br> }(t)<br>} - 动态增减需加额外同步（如用
sync.Mutex保护wg.Add(1)调用点），但通常说明设计已偏离简单并行模型，应考虑errgroup.Group
sync.Map 在非“读多写少”场景反而拖慢性能
sync.Map 是为「高并发读 + 偶尔写」优化的，内部用 read/write 分离 + 懒惰复制。一旦写操作占比超过 ~15%，它比普通 map + sync.RWMutex 更慢，且内存占用翻倍。
判断是否该用 sync.Map，看三个信号：
- 键集合基本稳定（不频繁增删 key）
- 90% 以上操作是
Load()或Range() - 没有强一致性要求（
sync.Map的Range()不保证看到最新写入）
否则直接用 map + sync.RWMutex，代码更可控，性能更可预测。
channel 替代 sync.Mutex 的边界在哪里
用 channel 实现同步（如用带缓冲 channel 当信号量、用 chan struct{} 控制临界区）看似优雅，但实际开销远高于 sync.Mutex：每次发送/接收涉及 goroutine 切换、调度器介入、内存分配（底层有锁和队列）。压测显示，纯本地临界区保护，channel 比 sync.Mutex 慢 3–5 倍。
channel 真正适用的场景是：
- 跨 goroutine 传递数据（不止是信号）
- 需要超时控制（
select+time.After） - 解耦生产者/消费者生命周期（如 worker pool 中任务分发）
把 channel 当作锁来用，是典型的“为抽象牺牲性能”，尤其在热点路径上要格外警惕。
