函数颜色理论
内容提要
文章用“函数颜色”比喻异步问题：红色为异步函数，蓝色为同步函数。同步函数无法调用异步函数，红色具有传染性，导致回调地狱。Promise、async/await 只是语法糖，未根治颜色问题。Go、Lua、Ruby 靠多线程或协程避免此问题。作者比较了操作系统线程、用户态线程和事件循环三种异步模型，指出没有绝对优雅的方案，各有取舍。
延伸解读
颜色问题的本质与传染性
文章用红蓝颜色比喻同步与异步函数，红色代表异步，蓝色代表同步。核心规则是同步函数不能调用异步函数，而异步函数可以调用同步函数。这导致一旦某个底层函数是异步的，所有调用它的函数都必须变成异步，形成“红色传染”。这种传染性使得代码中异步函数不断向上蔓延，最终导致回调地狱。Promise 和 async/await 只是语法糖，并未改变函数有颜色这一根本事实，因此在高阶函数或代码复用场景下，颜色问题依然存在。
语法糖的局限与高阶函数困境
Promise 和 async/await 改善了异步代码的书写体验，但并未消除函数颜色。例如，在数组的 map 方法中，如果回调是异步函数，map 本身是同步的，就无法直接使用 await。文章举例说明，即使用 async/await，在同步的高阶函数中调用异步函数仍然困难，因为高阶函数本身是蓝色的，不能等待红色函数。这表明语法糖只能缓解表面问题，无法根治颜色带来的根本限制，尤其是在需要组合和复用异步逻辑时。
三种异步模型的取舍
文章比较了操作系统线程、用户态线程和事件循环三种异步模型。操作系统线程模型最简单，由操作系统负责上下文切换，但需要语言支持。用户态线程（如 Go 的 goroutine）减少了切换开销，保持了函数的纯色性，但增加了并发漏洞和同步难度。事件循环模型（如 Node.js）避免了抢占式调度，减少了并发漏洞，但存在函数颜色问题，且一个事件的阻塞会冻结整个程序。作者强调没有绝对优雅的模型，每种方案都有其代价，选择取决于具体场景和权衡。
Q&A
什么是函数颜色理论？
函数颜色理论用颜色比喻函数的同步/异步属性：红色代表异步函数，蓝色代表同步函数。每个函数必须有一种颜色，且红色函数只能在红色函数中调用，蓝色函数不能调用红色函数。
为什么异步函数具有传染性？
因为同步函数无法调用异步函数，一旦某个函数调用了异步函数，它自身也必须变成异步函数。这种变化会沿着调用链向上传播，导致所有调用它的函数都不得不改为异步，就像红色染料扩散一样。
Promise 和 async/await 能彻底解决函数颜色问题吗？
不能。它们只是语法糖，让异步代码写起来更美观，但并没有改变函数有两种颜色的事实。同步函数仍然不能调用异步函数，颜色问题依然存在。
哪些编程语言没有函数颜色问题？为什么？
Go、Lua、Ruby 没有函数颜色问题。它们都支持多线程或协程（如 Go 的 goroutine、Lua 的 coroutine、Ruby 的 fiber），拥有多个可切换的调用栈，因此同步和异步代码可以自然混合。
事件循环模型是如何工作的？
事件循环是一个不断轮询任务的循环，程序被抽象为事件（任务）队列。当异步操作完成时，对应的回调事件被激活并加入队列，在下一轮循环中执行。它通过闭包捕获上下文来恢复现场，但会面临函数颜色问题。
三种异步模型（操作系统线程、用户态线程、事件循环）各有什么优缺点？
操作系统线程：编程简单，由操作系统管理上下文，但切换开销大。用户态线程（如 goroutine）：减少切换开销，保持函数纯色，但高并发下需同步原语，易引发并发漏洞。事件循环：无抢占式调度，减少并发漏洞，但有函数颜色问题，且一个事件阻塞会冻结整个程序。
