Mutex 还是 channel：Go 并发模型选型实战复盘

很多刚接触 Go 的开发者，几乎都会在某个深夜对着屏幕陷入沉思：这段代码到底该用 `sync.Mutex` 还是 `channel`？网上有各种“最佳实践”，有说“别用 Mutex，用 channel 传递所有权”的，也有说“channel 有开销，Mutex 更直接”的。我过去几年在生产环境里踩了不少坑，也做过几次小规模重构，想把一些实战中的选型经验和思考过程整理出来，希望能提供一些参考。

数据保护场景，选 Mutex 通常更自然

先看一个经典场景：多个 goroutine 需要并发读写一个共享的 `map[string]int`，比如统计在线人数或者请求计数。这种情况下，核心诉求是保护共享状态的一致性，goroutine 之间并不存在明显的“交接”或“流水线”关系，更像是一堆并发的调用者去访问同一个公共资源。

如果硬上 channel，假设把每个计数请求都打包成一封邮件塞进 channel，然后由单独的 consumer 去处理，逻辑上确实也能跑通。但仔细想想，你会付出额外的代价：代码变得不直观，每个读操作可能还要加一轮异步应答的等待；如果不小心设计成有锁甚至带缓冲的 channel，还得额外考虑缓冲大小、超时处理、关闭时机等问题，复杂度和心智负担明显上升。

此时直接用一个结构体包裹 `map`，里面嵌一个 `sync.RWMutex`，`Get` 用读锁，`Update` 用写锁，反而更简洁、可读性更高。读多写少的场景用 `RWMutex` 体验极佳，锁粒度非常细，性能也能满足绝大多数需求。

用 Mutex 保护数据，典型的思维模式是：先想清楚哪些操作会触碰共享内存，在最小作用域加锁，确保锁内的逻辑尽可能短小且不阻塞在 I/O 上。其实 Go 的内存模型加上编译器对锁的保护已经非常成熟，只要不搞出死锁或忘解锁（记得 `defer`），这条路是风险最低的。

任务编排与协作，channel 更符合直觉

另一种典型场景不是保护数据，而是多个 goroutine 协作完成某个流程。比如一个爬虫系统：一个 producer 去抓取 URL 列表，分发给多个 worker 去下载，然后结果汇总出来。这种场景里数据确实在 goroutine 之间流动，每个阶段只关心自己收到的内容，而且 worker 数量在运行时可能需要动态调整。

面对这种编排需求，如果强行用 Mutex 摊在一个共享 slice 上，然后再开一堆条件变量去等待任务调度，实现起来会异常拧巴。每一处 `for` 循环都可能要加上复杂的轮询和条件判断，还很容易造出“惊群效应”或者边界条件 bug。使用 channel，尤其是带缓冲的 channel，天然就支持优雅的 task 分发：producer 往里写，worker 从里头取，channel 本身还是一个线程安全的队列。

更重要的是，channel 能实现优雅退出。`close(ch)` 后，接收方通过 `v, ok := <-ch` 可以感知关闭并推出循环，能完全避免开发者自己手工管理一堆“退出状态”共享变量、`done` channel 以及 `sync.WaitGroup` 时可能出现的等待遗漏或提前返回的悲剧。

在编排场景里，使用 channel 更像是在用 goroutine 之间传递“责任”和“所有权”。模式清晰可变，哪个 goroutine 负责产生数据、哪个负责消费数据，代码的结构直接就反映出来了，读起来像在描述业务流程。

别被“真并发”绑架：效率和易读性要平衡

有不少人批判 Mutex 用多了就是在写 Java/C++ 的老路子，不够“Go 范”。这种声音有一定道理，但过于理想化。Go 官方确实有一句很有名的话：不要通过共享内存来通信，而应该通过通信来共享内存。然而现实中，很多东西本身就适合做共享状态，比如配置中心、全局的连接池管理器，或是访问极频繁的计数器。

反观 channel 也不是银弹：它有内存分配、goroutine 调度切换的开销，对于每秒上百万次操作的高频热点代码，channel 容易成为明显的性能瓶颈。使用无缓冲 channel 时，发送方和接收方必须同步就绪，内部涉及大量 goroutine 唤醒和阻塞，吞吐量通常远不如直接操作内存级别的锁操作。

抛开性能不谈，channel 也会引入更多的“隐式魔法”。一个带着三个 ch 参数的结构体，读懂它内部数据流转实际上需要跨行的直觉，这对新人并不友好。Mutex 的行为非常直白：几行锁内代码块，问题范围一目了然。工程实施上，“别人能轻松维护”可能比“看起来无比高并发”更重要和务实。

实战复盘：复合型方案更常见

在我经历过的真实项目里，大多数中期规模系统很少只用一把锁或者靠一个并发 fan-in/fan-out 流排列到底。比如在订单系统里，必然有一个订单池作为共享状态需要锁保护；对订单处理的结果投递，又经过一个 channel 派发到各个下游动作模块。这种做法既保证了数据安全，又通过 channel 给了各个组件解耦的可能性。

所以在设计初期，我不再纠结于“用 Mutex 还是 channel”，而是先问自己几个问题：
- 这段代码的核心目的是防竞争保护共享数据，还是按步骤传递任务数据？
- 有多少个生产者和消费者？它们之间的耦合程度如何？
- 是否有动态创建或取消的 goroutine，需要可控的退出通知？
- 读多写少的共享资源，是否可以用读写锁提高并发能力？
- 用 channel 是否会使代码的职责分配和结构优雅程度有实质提升？

如果答案是防数据竞争，闭眼选 Mutex；如果是协作编排、生命周期管理，优先考虑 channel；如果两者纠缠在一起，那就分别设计，不要指望用一个机制包打天下。

总结

Mutex 和 channel 不是对立面，它们只是 Go 并发工具箱里位于不同抽象层级的工具。一个解决的是“互相不可见的数据安全”，另一个表达的是“流程间通信的意图”。判断标准不在于 Google 或者某位大牛说了什么，而在于你写的这段代码贴近哪一类问题本质。写好 Go 并发，某种程度上就是学会随机制调整自己的思维方式，Mutex 和 channel 各有各的性能边界和表达边界，真正的高手，恰恰是根据现实约束在两者之间自由进出的人。