在编写可复用的代码库时，开发者常常面临一个隐蔽却影响深远的设计困境：一旦某个底层函数需要执行异步操作，这种 "异步性" 会像病毒一样向上传播，迫使整个调用链上的函数都改变其定义方式。这种现象被称为 "函数着色"（Function Coloring），它不仅影响代码的可读性，更在根本上破坏了函数组合的自由度。
什么是函数着色
函数着色是一种形象化的比喻，用来描述编程语言中同步函数与异步函数之间的严格分界。想象所有函数都被标记为两种颜色之一：蓝色代表同步函数，红色代表异步函数。这种着色机制遵循几条严格的规则：
第一，每个函数都有颜色，不存在无色的函数。第二，调用函数时必须使用与其颜色匹配的调用语法。第三，也是最关键的一条：红色函数可以调用蓝色函数，但蓝色函数绝对不能调用红色函数。第四，红色函数的调用成本更高 —— 它们无法直接在表达式中使用，不能配合传统的异常处理机制，也无法在任意控制流结构中自由嵌入。第五，某些核心库函数注定是红色的，比如涉及 I/O 的操作。
这种设计在 JavaScript、Python、C#、Dart 等语言中普遍存在。当你使用 Node.js 编写代码时，一旦某个函数采用回调模式返回结果，它就变成了红色函数。所有希望调用它的函数也必须变成红色，这种 "颜色传染" 会一直蔓延到程序的最顶层。
组合壁垒的形成
函数着色对代码组合造成的阻碍体现在多个层面。首先是高阶函数的困境。设想你正在实现一个通用的 filter 函数，用于筛选集合中满足特定条件的元素。如果 filter 本身被定义为蓝色函数，那么传入的谓词函数也必须是蓝色的 —— 这意味着你无法在筛选逻辑中执行任何异步操作，比如从数据库验证某个字段的存在性。
反过来，如果你将 filter 定义为红色函数以支持异步谓词，那么所有调用 filter 的代码都必须变成红色。这种权衡在库设计中尤为痛苦：你希望提供灵活的 API，但函数着色迫使你在同步与异步之间做出排他性选择，或者不得不维护两套几乎相同的实现。
其次是代码复用的障碍。假设你实现了一个通用的图算法，比如 Dijkstra 最短路径。最初这是一个纯粹的计算逻辑，被设计为蓝色函数。后来你发现需要在权重计算中查询外部服务，于是将它改为红色。但这样一来，所有原本调用这个算法的蓝色函数都不得不改为红色，引发连锁反应。
缓解方案及其局限
面对函数着色带来的痛苦，社区发展出了多种缓解策略，但每种方案都有其边界。
回调函数是最原始的异步模式。它将后续操作封装为函数传递给异步操作，在操作完成后执行。这种模式的本质是将调用栈上的状态手动转移到堆上的闭包中，技术上称为 "续传风格变换"（Continuation-Passing Style）。问题在于，这种变换需要开发者手动完成，导致代码横向延展形成 "回调地狱"，错误处理也变得支离破碎。
Promise/Future 是对回调的包装，将异步操作抽象为对象。它们提供了链式调用的能力，使代码结构稍微清晰。但 Promise 并未消除函数颜色 —— 它仍然是红色的，只是让红色函数的编写稍微不那么痛苦。你无法在蓝色函数中直接获取 Promise 的结果，异常处理也无法使用传统的 try/catch。
Async/Await 是语法层面的重大改进。通过 await 关键字，编译器自动完成 CPS 变换，将函数在 await 点拆分为两部分。这使得异步代码看起来几乎与同步代码无异，可以使用表达式、异常处理和控制流。然而，这种便利性是有代价的：async/await 并没有消除函数颜色，它只是让红色函数更容易编写。
被标记为 async 的函数仍然返回包装对象（JavaScript 的 Promise、C# 的 Task），调用者仍然需要使用 await 来解包。如果你试图在蓝色函数中调用红色函数，编译器会拒绝。颜色传染依然存在，只是传播的方式变得优雅了一些。
根本解决之道：消除颜色
既然函数着色的根源在于同步与异步的分裂，那么彻底的解决方案就是消除这种分裂。Go、Lua 和 Ruby 等语言通过不同的机制实现了这一点，它们的共同点是：支持可切换的独立调用栈。
Go 语言的 goroutine 是这一思想的典范。在 Go 中，所有的 I/O 操作看起来都是同步的 —— 它们只是普通的函数调用，返回结果，阻塞当前执行流。但关键在于，当一个 goroutine 阻塞在 I/O 上时，Go 的运行时会自动将其挂起，切换到其他可执行的 goroutine，而不会阻塞整个程序。
这意味着在 Go 中不存在红色函数与蓝色函数的区别。所有函数都是 "蓝色的"—— 它们使用相同的语法、相同的错误处理机制、可以在任何控制流中自由组合。并发成为程序结构的组织方式，而不是函数定义的属性。
这种模型的技术基础是调用栈的物化（Reified Callstack）。当执行异步操作时，传统语言必须完全展开调用栈，将状态保存在闭包中。而拥有独立调用栈的语言可以直接暂停整个栈，保留完整的执行上下文，待操作完成后再恢复。这避免了 "红色函数只能被红色函数调用" 的限制。
对库设计的启示
理解函数着色问题对 API 设计具有直接的指导意义。如果你正在设计一个跨语言的库，或者在一个支持多种并发模型的语言中工作，以下原则值得考虑：
优先提供同步 API。如果底层实现允许，暴露同步接口是更通用的选择。调用者可以在需要时自行包装为异步，但反向转换往往困难得多。
隔离 I/O 边界。将 I/O 操作集中在特定的模块或层中，避免让着色渗透到核心业务逻辑。通过依赖注入或接口抽象，可以让核心逻辑保持 "蓝色"，只在最外层处理 "红色" 的复杂性。
考虑语言的并发模型。在 JavaScript 或 Python 中，async/await 是事实标准，必须接受函数着色的存在并设计相应的 API 结构。在 Go 或 Erlang 中，则可以充分利用其无着色特性，编写更自然的顺序代码。
避免过度抽象。不要为了 "支持两种模式" 而维护两套平行的 API，这会带来长期的维护负担。选择一个与语言生态一致的策略，并在文档中明确说明其约束。
函数着色不是编译器作者的恶意，而是异步 I/O 与调用栈管理之间张力的必然产物。async/await 让这种张力变得可以忍受，但只有从根本上重新思考并发模型，才能真正解放代码组合的自由。对于开发者而言，理解这一问题的本质，有助于在特定语言的约束下做出更明智的设计决策。
参考来源
- Nystrom, B. (2015). "What Color is Your Function?" journal.stuffwithstuff.com. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。