Mutex 适合保护共享状态，性能开销更低；Channel 适合协程间通信，内部调度开销较大。高并发保护变量时严禁用 Channel 模拟锁，否则会导致显著的性能下降和语义混淆。
先说结论：保护共享变量首选 Mutex，协程协作通信首选 Channel，两者职责分明不可混用。
- 适合：高频低延迟的共享资源保护场景，如计数器、缓存、配置快照。
- 重点看：数据是否需要流动，若仅需访问控制，Channel 的调度开销会成为瓶颈。
- 别忽略：用 Channel 模拟互斥锁在高并发下比 Mutex 慢数倍，且容易引发死锁或 Panic。
快速处理思路
面对并发选型问题，先判断数据是“共享”还是“流动”。保护 map、结构体字段或计数器时，直接使用 sync.Mutex 或 sync.RWMutex 加锁。仅在需要传递数据所有权、编排任务流程或实现生产者 - 消费者模型时，才使用 Channel。
为什么会这样
Mutex 底层基于原子操作和等待队列，开销主要集中在锁竞争；Channel 底层涉及 hchan 内部锁、缓冲区数据拷贝和 Goroutine 调度。
Go 的 Mutex 经历了多次演进，当前版本使用饥饿模式防止 Goroutine 饥饿，正常模式下新来的 Goroutine 与被唤醒的 Goroutine 竞争锁。Channel 的发送和接收操作需要获取 mutex 锁，检查等待队列，若无缓冲区可用还需挂起 Goroutine，流程更复杂。基准测试显示，高并发下用 Channel 模拟锁比 sync.Mutex 慢 3–5 倍，因为每次收发要两次 hchan 内部锁加 buffer copy，而 Mutex 是一次原子操作。
分步处理
1. 识别共享资源：若多个 Goroutine 读写同一 map、结构体字段或全局配置，必须用 mu.Lock()/mu.RLock() 保护，否则会导致 panic 或数据错乱。
2. 选择锁类型：读多写少场景（如服务健康状态）优先用 sync.RWMutex，避免读操作互相阻塞；单个整数计数器直接上 atomic.AddInt64，比锁和 Channel 都轻。
3. 设计通信流程：当需要表达“谁提供、谁消费、谁退出”时，使用 Channel。明确标注方向 chan<- T（只发）、<-chan T（只收），生产者负责 close，消费者绝不 close。
怎么验证是否生效
使用 go test -bench 进行基准测试，对比 Mutex 和 Channel 方案的 ns/op 和 allocs/op。运行 go tool pprof 查看 mutex profile，确认锁竞争是否成为瓶颈。观察程序在高并发压测下是否有延迟抖动，Channel 模拟锁的延迟抖动在压测环境会立刻暴露。
常见坑
1. 并发写 map：Go 运行时对并发写 map 有严格检查，不加锁直接并发修改会 panic:fatal error: concurrent map writes。
2. Channel 当锁用：用 ch + <-ch 实现互斥，语义混淆且性能差。标准库里所有共享状态保护全用 Mutex，没一个靠 Channel。
3. 锁粒度过粗：别把 http.Get、db.Query、time.Sleep 放进 mu.Lock() 和 mu.Unlock() 之间，这等于让所有 Goroutine 排队等 IO。
常见问题
Channel 和 Mutex 哪个更快？
保护共享变量时 Mutex 更快。Channel 内部实现涉及更多调度和内存分配，仅仅是保护一个计数器或状态变量，Mutex 通常是更好的选择。
什么时候必须用 Mutex？
操作涉及 map、struct 字段、全局配置、缓存快照时必须用 Mutex。这不是警告，是硬性崩溃风险，不加锁直接并发修改会 panic。
Atomic 能替代 Mutex 吗？
仅适用于单个整数计数器。atomic 无法覆盖 map、slice、struct 整体，这些操作不是原子的，不能替代 Mutex 保护复杂结构。
参考来源
Go 并发原语深度剖析:Channel 与 Mutex 的性能博弈
Go Mutex 与 Channel 对比使用场景
什么时候该用 Channel，什么时候该用 Mutex?
Go 语言面试如何对比 mutex 与 channel_Golang 并发同步方案选型