异步编程的"颜色"陷阱
推荐指数 46.0 NO. 012 · 2026.05.27
发布2026/05/26Score59Comments48
为什么值得看
经典文章揭示编程语言中同步/异步函数分裂的设计缺陷，强制开发者用不同"颜色"标记可挂起与不可挂起的代码。十年后的今天，Rust async/await、Python asyncio 仍受此困扰，值得重新审视语言设计选择。
编辑判断
这篇文章写于 2015 年，但 Go 的 goroutine 和 Zig 的 async 取消设计正在尝试打破这个诅咒。Go 用 M:N 调度让同步代码直接获得异步能力，而 Zig 走得更远——编译期决定是否生成异步代码，同一套语法兼容两种模式。
如果你在用 Rust，async fn 和 sync fn 的互操作痛点正是此文预言的实现；如果你在设计新语言或 DSL，这是必读的反模式教材。当前 LLM 代码生成场景下，"颜色"问题被进一步放大——模型频繁在 sync/async 边界出错，因为训练数据里两种模式混杂且无显式标记。
社区反馈
意见分歧 46 条评论
核心争论：同步还是异步？社区分裂为"Go/Erlang运行时隐藏复杂度派"与"同步代码+扩容更简单派"
My first ever EM showed me this piece ~10 years ago, and I still think about it a lot. One pattern I've adopted is to keep as much code to be synchronous as possible. On larger teams, especially when the slop-cannon is really going, I can at least depend on codeowners to tag me if someone tries to c
For Python backends I've seen good success with just making it company policy that everything is synchronous (normal-colored) and bypassing the developer overhead from async/await. Cooperative multitasking is a pain because, well, it requires cooperation. You can go pretty far by just adding mo
I just do not want to do async in Python. If you need async its questionable whether Python is a good choice at all, and if you use Python maybe look at another solution if at all possible (even using more processes and throwing hardware at it).