JavaScript怎么实现协程：Generator与async/await的模拟机制

一、单线程下的协程诉求：协作调度与无栈模型

在传统的系统级并发编程中，线程（Thread）由操作系统内核进行抢占式调度，而协程（Coroutine）则是一种运行在用户态的轻量级并发单元。协程最大的特征是“协作式调度”——它不依赖时钟中断强制切换，而是由代码显式让出（yield）控制权，在适当时机再被重新唤醒恢复执行。

在面对高并发 I/O 任务时，操作系统线程由于需要为每个执行单元预分配数十 KB 到数 MB 的物理调用栈，且线程切换涉及 CPU 寄存器与内核上下文的保存，开销相对昂贵。这引出了协程的两种主流分类：

• 有栈协程（Stackful Coroutine）： 每个协程拥有独立的运行时调用栈（如 Go 语言中的 Goroutine）。它可以嵌套在任意深度的子函数调用中随意挂起，系统会完整保存整个调用栈链。
• 无栈协程（Stackless Coroutine）： 协程没有独立的系统调用栈，所有的暂停操作只能在协程函数的最顶层或被专门标记的上下文中发生。挂起时，局部变量与执行指针被打包成轻量的普通对象暂留在堆内存中。

JavaScript 引擎（如 Google V8）采用单主线程模型，主调用栈（Call Stack）必须保持连续运作以响应用户的界面交互和事件循环。因此，JavaScript 无法且无需引入有栈多线程协程，而是选择了更加轻量、不会阻塞主栈的无栈协程模拟机制。

图 1 Generator 执行上下文在堆内存与主调用栈之间的保存与恢复机理

如图 1 所示，普通函数在执行时入栈，执行完毕后其栈帧立即弹出并被垃圾回收销毁。而 Generator 函数被调用时并不立即执行内部代码，而是在 V8 的堆内存中实例化一个 GeneratorObject 对象。该对象持久化保存了当前生成器的内部运行状态（如 suspendedStart、suspendedYield、executing 等）、局部作用域变量表以及程序计数器（YieldPoint）。当执行到 yield 时，主线程栈帧安全退出，执行权让出；当下一次调用 .next() 时，引擎重新从堆中取出该上下文恢复现场，从而在单线程中实现了协程挂起与恢复的核心特质。

二、Generator 的挂起与恢复：模拟协程的语法基石

ECMAScript 2015 (ES6) 引入的 Generator（生成器函数）为 JavaScript 提供了暂停与恢复执行的原生语法。生成器遵循迭代器协议，是构建协程的底层基石。

1. 双向数据通信协议

真正的协程不仅需要暂停让权，还必须能够与调度者进行双向数据交换。Generator 通过 yield 表达式向外产出数据，同时接收外部通过 next(value) 注入的数据：

function* coroutineTask() {
  console.log("协程启动");
  // 挂起点 1：向外产出 '等待输入A'，并让出控制权；恢复时接收外部传入的值赋给 a
  const a = yield "等待输入A";
  console.log("协程恢复，收到参数 a:", a);

  // 挂起点 2：向外产出 a * 2，恢复时接收 b
  const b = yield a * 2;
  console.log("协程恢复，收到参数 b:", b);

  return a + b;
}

// 实例化生成器，此时处于 suspendedStart 状态
const gen = coroutineTask();

// 首次调用 next()：启动协程至第一个 yield 处挂起
const step1 = gen.next();
// 输出: 协程启动
// step1 的值为: { value: "等待输入A", done: false }

// 第二次调用 next(10)：恢复协程，将 10 作为上一个 yield 表达式的返回值赋给 a
const step2 = gen.next(10);
// 输出: 协程恢复，收到参数 a: 10
// step2 的值为: { value: 20, done: false }

// 第三次调用 next(5)：恢复协程，将 5 赋给 b，运行至 return
const step3 = gen.next(5);
// 输出: 协程恢复，收到参数 b: 5
// step3 的值为: { value: 15, done: true }

2. 异常捕获与提前终止

除了正常传值，协程调度者还可以通过 gen.throw(error) 将异常从外部抛入生成器内部未执行完毕的代码点，生成器内部可以使用常规的 try...catch 块直接捕获：

function* safeTask() {
  try {
    yield "尝试执行危险网络请求";
  } catch (err) {
    console.warn("协程内部捕获到调度器抛入的错误:", err.message);
    return "已降级处理";
  }
}

const g = safeTask();
g.next(); // 运行至 yield 处挂起
// 外部调度器发现网络异常，向协程注入错误
const res = g.throw(new Error("网络超时 504"));
// res 的值为: { value: "已降级处理", done: true }

三、弥补控制权缺口：基于 Promise 的自动执行器（Runner）

2014 年左右，著名开源开发者 TJ Holowaychuk 发布了著名的 co 库。co 的核心思想就是将 Generator 与 Promise 结合，实现了一个自动步进递归的协程执行器（Coroutine Runner）。

执行器的运作闭环非常严密：生成器产出 Promise，执行器监听该 Promise 的完成状态；当 Promise 变为 Fulfilled 时，微任务回调自动触发，执行器带着结果调用 next(data) 唤醒生成器；若变为 Rejected，则调用 throw(err) 唤醒异常分支。

图 2 基于 Promise 的自动执行器（Runner）调度循环流程图

完整手写实现：轻量级协程执行器

下面是一个符合标准行为的无外部依赖轻量级 runCoroutine 执行器实现。前后变量与环境保持规范一致：

/**
 * 协程自动执行器
 * @param {Function} generatorFunction 生成器函数
 * @returns {Promise} 返回包含最终决议结果的 Promise
 */
function runCoroutine(generatorFunction, ...args) {
  return new Promise((resolve, reject) => {
    // 1. 初始化生成器实例
    const gen = generatorFunction(...args);

    // 2. 递归步进函数
    function step(nextF) {
      let nextResult;
      try {
        // 执行当前步进，可能触发 gen.next() 或 gen.throw()
        nextResult = nextF();
      } catch (e) {
        // 如果生成器内部未捕获异常并抛出，直接终止外层 Promise
        return reject(e);
      }

      const { value, done } = nextResult;

      // 3. 检查是否迭代完毕
      if (done) {
        return resolve(value);
      }

      // 4. 将产出的 value 统一转为标准 Promise，挂载回调
      Promise.resolve(value)
        .then(
          // 异步成功：带着结果继续调用 next 唤醒协程
          res => step(() => gen.next(res)),
          // 异步失败：将异常通过 throw 回注到协程内部
          err => step(() => gen.throw(err))
        );
    }

    // 启动首次执行
    step(() => gen.next());
  });
}

使用执行器运行业务协程

有了执行器后，原本嵌套层层回调或手动 .then() 链条的代码，就可以像同步代码一样直观扁平地书写：

// 模拟两个异步 API 接口
function fetchUserToken() {
  return new Promise(resolve => setTimeout(() => resolve("TOKEN_XYZ_123"), 100));
}

function fetchUserProfile(token) {
  return new Promise((resolve, reject) => {
    if (!token) return reject(new Error("无效 Token"));
    setTimeout(() => resolve({ id: 101, name: "Alice", role: "admin" }), 100);
  });
}

// 业务协程任务
function* userWorkflow() {
  console.log("开始查询用户信息...");
  // yield 后面直接跟 Promise，执行权让出，等待完成后自动携带结果唤醒
  const token = yield fetchUserToken();
  console.log("成功获取 Token:", token);

  const profile = yield fetchUserProfile(token);
  console.log("成功获取用户画像:", profile.name);

  return profile;
}

// 运行协程
runCoroutine(userWorkflow).then(finalData => {
  console.log("协程执行完毕，最终返回值:", finalData);
}).catch(err => {
  console.error("协程失败:", err);
});

在这个运行过程中，JavaScript 的单线程并未被任何 sleep 或阻塞锁占用。当 fetchUserToken() 处于等待状态时，主线程继续处理其它事件循环任务；当底层定时器或网络 I/O 决议时，微任务队列激活 step 回调，重新将上下文推入调用栈。这就是 JavaScript 协程“协作而不阻塞”的核心秘密。

四、从模拟到原生：async/await 的本质剖析

由于“Generator + Promise 执行器”这一模式在社区中被证明极为高效且符合直觉，ECMAScript 委员会在 ES2017 (ES8) 中正式将其规范化，推出了语言内置的 async 与 await 关键字。

图 3 协程模拟执行器与 ECMAScript 原生 async/await 编译映射对照

1. 语法映射的等价性

从语义和底层运行机制上观察，async/await 完全等价于执行器包装的生成器：

• async function 标识： 等价于一个被 runCoroutine() 执行器自动包裹并返回 Promise 的函数。
• await expr 表达式： 等价于 yield Promise.resolve(expr)。无论其后是 Promise 还是普通字面量，引擎均会将其视作微任务调度点进行协作让权。
• try...catch 结构： 原生捕获 await 后 Promise 发生 rejection 时的异常，底层对应执行器调用的 gen.throw()。

2. Babel 编译器视角的转换产物

在将现代 ES 代码编译为向后兼容代码时，Babel 等编译器使用的辅助函数 _asyncToGenerator 就是上述执行器模式的标准工业级翻版：

// 开发者编写的现代 async 代码
async function loadData() {
  const res = await fetch("/api");
  return res.json();
}

// Babel 编译转换后的等价 JavaScript 产物结构
function loadData() {
  return _asyncToGenerator(function* () {
    const res = yield fetch("/api");
    return res.json();
  }).apply(this, arguments);
}

3. 现代 V8 引擎对原生 async/await 的深度优化

虽然机制原理相同，但现代 V8 引擎中的原生 async/await 比用户态的 co 库执行速度更快、内存占用更低。主要技术优化包括：

1. 跳过冗余 Promise 包装： 早期的模拟方案在每次 yield 时都会创建新的 Promise 对象和微任务闭包。2018 年 V8 团队优化了规范实现，当 await 后紧随一个已经是原生且合法的 Promise 时，不再额外嵌套包装 Promise 实例，大幅减少堆内存分配。
2. 零成本异步调用栈追踪（Zero-Cost Async Stack Traces）： 用户态生成器在 yield 挂起后，主执行栈完全断开，一旦在异步回调中报错，堆栈追踪往往只显示执行器内部的递归调用，原始调用上下文丢失。而 V8 在引擎 C++ 内部维护了 await 链条的父子上下文引用，能够在抛出错误时无额外开销地重构完整的异步长调用栈。

五、实战注意：协程机制下的常见陷阱与控制边界

深入理解 JavaScript 的无栈协程模拟机制，不仅有助于掌握原理，更能避免在日常开发中踩入隐蔽的并发陷阱。

1. 警惕非必要的“串行化等待”

await 给予了代码像同步代码一样的直观外观，但容易让开发者下意识地将互不依赖的异步操作写成顺序执行，导致性能大幅降低：

// ❌ 错误做法：人为造成串行阻塞，总耗时 = 200ms + 300ms = 500ms
async function fetchBad() {
  const user = await fetchUser(); // 等待 200ms
  const posts = await fetchPosts(); // 再等待 300ms
  return { user, posts };
}

// ✅ 正确做法：利用底层事件循环的并发能力，总耗时 = max(200ms, 300ms) = 300ms
async function fetchGood() {
  const userPromise = fetchUser();
  const postsPromise = fetchPosts();
  
  // 协程在此处等待两个并发任务同时决议
  const [user, posts] = await Promise.all([userPromise, postsPromise]);
  return { user, posts };
}

2. 无栈协程的“单层作用域限制”

由于 JavaScript 协程是无栈的，yield 和 await 无法像有栈协程那样跨越常规回调函数的栈帧进行挂起。最典型的错误发生在使用数组的 forEach 方法时：

// ❌ 陷阱：forEach 的回调是普通同步函数，内部 await 不会阻塞外部循环
async function processItems(items) {
  items.forEach(async (item) => {
    await saveToDatabase(item); // 异步启动后立即脱离外层控制
  });
  console.log("这里会立即输出，此时数据并未存储完毕！");
}

// ✅ 正确做法：使用支持协程让权语法的 for...of 循环，或者使用 Promise.all
async function processItemsCorrectly(items) {
  for (const item of items) {
    // 在当前协程上下文中真正按序挂起等待
    await saveToDatabase(item);
  }
  console.log("全部数据已安全落库。");
}

六、体系总结：JavaScript 协程运行机制全貌

回顾全文，JavaScript 实现协程的技术路径是一场在单线程约束下关于“状态机”与“事件循环”的优雅架构演进：

图 4 JavaScript 协程体系与单线程事件循环架构全景总结

我们可以将这套模拟机制的核心要点归纳如下：

通过这套设计，JavaScript 既捍卫了单线程架构无需互斥锁、无死锁风险的高效与简单，又成功赋予了开发者以清晰的同步代码结构书写复杂异步任务的能力。