Go channel 不是高级锁，它是一种组织并发的语言

Thu, 21 May 2026 16:02:00 +0800

有人为了写得“更 Go”，把一个简单 cache 包成了 channel 协议。

每次 Get，先构造 request，发给 owner goroutine，再等 response channel 返回。还要处理 context、close、退出顺序、goroutine 泄漏。

最后代码确实没有显式 sync.RWMutex 了。

但问题也来了：本来一把锁能讲清楚的事，被写成了一套小型 RPC。

这不是优雅。

这是绕远。

Go 社区有一句被反复引用的话：

Do not communicate by sharing memory; instead, share memory by communicating.

很多人把它理解成：Go 不喜欢锁，channel 更高级，能用 channel 就别用 mutex。

这个理解太粗了。

channel 的价值不是把锁藏起来，而是把通信显式写出来。mutex 也不是“不 Go”，它就是保护共享状态的直接工具。

真正要问的不是：channel 和 mutex 谁更高级？

真正要问的是：你现在到底是在传东西，还是在护东西？

channel 首先讲的是结构，不是性能

Rob Pike 在那场很有名的演讲《Concurrency is not Parallelism》里，一直在压一个区分：concurrency 是 structure，parallelism 是 execution。

并发不是“同时跑得更快”的同义词。

并发先是一种组织程序的方式：把一件事拆成多个可以独立执行的单元，再让它们通过通信协调。