function formatUserName(user) {
  return `${user.firstName} ${user.lastName}`;
}

async function formatUserName(userId) {
  const user = await db.getUser(userId);        return `${user.firstName} ${user.lastName}`; }

async function displayHeader(userId) {           const name = await formatUserName(userId);     console.log(`Hello, ${name}`);
}

async function renderPage(userId) {              await displayHeader(userId);                   }

函数着色到了库的层面，变成一个两难选择：写同步库，异步用户用不了；写异步库，同步用户要调用就必须引入一整套异步运行时——比如 Rust 的 Tokio 或 Python 的 asyncio 事件循环，原本简单的调用变成了先初始化运行时、再注册回调、再处理异常；两个都写，API 面积翻倍，测试矩阵翻倍，维护负担翻倍。

Python 是最典型的例子： requests 库（同步）和 aiohttp 库（异步）是两个独立项目，由不同作者分别实现同一个功能——发 HTTP 请求。后来 httpx 出现，同时提供同步和异步接口。但这恰恰说明函数着色把事情搞复杂了： httpx 的"统一"是对分裂问题的补救，而不是分裂不存在。

到了生态层面，函数着色直接导致运行时分裂。Rust 的异步生态围绕 Tokio、async-std、smol 三个互不兼容的运行时被割裂了。它们各自实现了 TCP 流、定时器等基础类型，一个为 Tokio 写的库没法直接在 async-std 上跑。流行的 HTTP 客户端 reqwest 直接绑定了 Tokio。

这意味着库作者面临两难：选 Tokio，锁定用户选择；写运行时无关的抽象层，增加复杂度和性能开销。结果是生态围绕"颜色"割裂，而不是围绕功能分工。

async function loadDashboard(userId) {
  const user = await getUser(userId);
  const orders = await getOrders(user.id);              const recommendations = await getRecommendations(user.id);   return { user, orders, recommendations };
}

function getUser(id) {
  return new Promise(r => setTimeout(() => r({id, name: 'Alice'}), 100));
}

function getOrders(userId) {
  return new Promise(r => setTimeout(() => r(['order1', 'order2']), 100));
}

function getRecommendations(userId) {
  return new Promise(r => setTimeout(() => r(['rec1', 'rec2']), 100));
}

async function loadSequential(userId) {
  const start = Date.now();
  const user = await getUser(userId);
  const orders = await getOrders(user.id);
  const recommendations = await getRecommendations(user.id);
  console.log(`顺序执行耗时: ${Date.now() - start}ms`);
  return { user, orders, recommendations };
}

async function loadParallel(userId) {
  const start = Date.now();
  const user = await getUser(userId);
  const [orders, recommendations] = await Promise.all([
    getOrders(user.id),
    getRecommendations(user.id)
  ]);
  console.log(`并行执行耗时: ${Date.now() - start}ms`);
  return { user, orders, recommendations };
}

(async () => {
  await loadSequential(1);
  await loadParallel(1);
})();

Clojure 的 core.async 库用了另一种方式回避着色。它的核心抽象是 channel（通道），函数返回 channel 而不是 Promise 或值。调用者自行决定怎么消费这个 channel：同步调用者用 <!! 阻塞线程取值，异步调用者在 go 块里用 <!= 暂停状态机取值。

;; 函数返回 channel，不区分 sync/async
(defn fetch-user [id]
  (let [ch (chan)]
    (thread                              ;; 在独立线程中执行 I/O
      (>!! ch {:id id :name "Alice"}))   ;; 结果放入 channel
    ch))                                 ;; 返回 channel

;; 同步调用者：阻塞等待结果
(let [user (<!! (fetch-user 1))]
  (println user))

;; 异步调用者：在 go 块中非阻塞等待
(go
  (let [user (<! (fetch-user 1))]
    (println user)))

fetch-user 的签名不包含任何颜色标记——它只返回一个 channel。同步和异步调用者用各自的取值方式消费同一个 channel，函数本身不需要改变。Clojure 把"怎么执行"的决定权交给了调用者，而不是强制编码在函数签名里。

Elisp 从未引入 async/await。Emacs 是单线程运行的，异步操作通过回调（ make-process 、 make-network-process ）或子进程实现。所有函数都是"蓝色"的，不存在着色问题。代价是 Emacs 主线程内部无法真正并行处理 I/O（子进程可以并行，但 Elisp 代码本身只能串行执行）。

这些方案的共同思路是：不让"怎么执行"的细节泄漏到"做什么"的接口里。函数签名应该表达业务意图，而不是执行策略。