sync.Mutex 比 channel 快得多，因其底层基于原子指令和 futex，无内存分配与调度开销；而 channel 涉及 runtime.hchan 锁、goroutine 状态切换及调度器介入，开销高一个数量级。
sync.Mutex 在绝大多数临界区保护场景下比 channel 快 3–5 倍，且语义清晰、可重入、panic 安全；channel 不是锁的替代品，硬套会引入死锁风险和不可靠释放。
为什么 sync.Mutex 比 chan struct{} 同步快得多
底层机制完全不同：sync.Mutex 是原子指令 + futex 的轻量组合，无内存分配、无 goroutine 调度介入；而每次 ch 或 <code><-ch 都要先获取 runtime 内部的 hchan.lock（一个隐藏的 mutex），再操作 sendq/recvq 队列，还可能触发调度器唤醒。实测 100 万次临界区进入，sync.Mutex 耗时约 30ms，同等逻辑用 unbuffered chan struct{} 超过 200ms。
常见错误现象：用 make(chan struct{}, 1) 模拟锁，结果在高并发压测中吞吐骤降、P99 延迟飙升——这不是 bug，是设计使然。
- 有缓冲 channel 的“伪非阻塞”假象掩盖了实际同步开销
- channel 操作隐含内存分配（如首次创建 hchan 结构体）
- runtime 调度器参与带来不可预测的延迟毛刺
哪些场景下 channel 的同步行为不可替代
channel 的价值不在“锁”，而在“通信伴随所有权移交”或“多路协作编排”。当同步天然绑定数据流转时，它才是正解。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 生产者构建完
map[string]int后通过ch <- data移交所有权，消费者接收即获得独占访问权 - 多个 worker 完成任务后向
done chan struct{}发信号，主 goroutine 用for i := 0; i < n; i++ { <-done }等待全部结束 - 需要
select同时监听网络连接、定时器、关闭信号——sync.Mutex根本不支持这种非阻塞多路等待
误用典型：用 chan 保护一个计数器自增（counter++）或防止并发写同一 slice——这是削足适履，既慢又难维护。
panic 时 sync.Mutex 和 channel 的释放可靠性差异
sync.Mutex 可靠：只要把 mu.Unlock() 放在 defer 中，即使 goroutine panic 也能保证释放。
channel 不可靠：用 ch <- struct{}{} “加锁”后若发生 panic，<-ch 永远不会执行，“锁”就永远卡死，后续所有 goroutine 在该 channel 上阻塞，形成静默死锁。
- 没有等价于
Unlock()的“安全释放”原语 - 无法嵌套调用（比如递归函数中重复“加锁”）
- 不区分读写权限，无法实现类似
RWMutex的语义
底层真相：channel 其实也依赖 mutex
Go 运行时源码（runtime/chan.go）里，hchan 结构体自带一个 lock sync.Mutex 字段，专用于保护其内部队列（sendq、recvq、qcount）的并发访问。你调用 ch <- 或 <-ch，本质是 runtime 替你加了一层隐藏的锁——所以 channel 的线程安全不是魔法，而是用 mutex 换了层包装。
这个细节常被忽略：你避开了显式写 mu.Lock()，却让 runtime 默默扛起了更重的同步负担，还失去了对锁生命周期的控制权。
