generator本身不执行异步操作,仅提供暂停/恢复机制;需搭配外部执行器(如co库)才能自动运行异步任务,执行器逻辑取决于采用thunk(函数包裹回调)还是promise(yield后等待resolve),两者传值时机与错误处理方式不同,但均依赖递归驱动迭代器,而async/await正是此模式的语法糖。

Generator 本身不执行异步操作,它只提供暂停与恢复的机制。要让它“自动跑完”一串异步任务,必须搭配外部执行器(runner),而执行器的设计方式取决于你用的是 Thunk 函数 还是 Promise —— 两者传递值的时机和方式不同,导致执行逻辑有本质区别。
Thunk 版:靠函数包裹异步逻辑,执行器只管“调用回调”
Thunk 函数的核心是:把异步操作封装成一个“无参函数”,这个函数内部调用原始异步方法,并把回调交给外部来决定。
例如读文件的 Thunk 化写法:
const readFileThunk = fileName => callback => {
fs.readFile(fileName, 'utf8', callback);
};
Generator 内部 yield 的就是一个 thunk:
function* main() {
const data1 = yield readFileThunk('a.txt');
const data2 = yield readFileThunk('b.txt');
return data1 + data2;
}
执行器只需接收 thunk、调用它、把结果传回 next:
- 每次 next() 得到一个 { value: thunk, done: false }
- 执行 thunk(cb),cb(err, res) → 若 err 就 throw,否则用 res 调用 next(value)
- 循环直到 done === true
这种模式下,Generator 不依赖 Promise,兼容老环境,但需手动构造 thunk,且错误处理需靠 try/catch + iterator.throw。
Promise 版:yield 返回 Promise,执行器负责 resolve 后续传值
更主流的做法是 yield 一个 Promise 实例,让执行器等待其完成再推进流程:
function* fetchFlow() {
const user = yield fetch('/api/user').then(r => r.json());
const posts = yield fetch(`/api/posts?uid=${user.id}`).then(r => r.json());
return { user, posts };
}
执行器的关键逻辑是:
- 调用 generator().next() 启动
- 若 result.value 是 Promise,用 .then() 拿到值后递归调用 next(value)
- 若出错,用 iterator.throw(error) 抛给 Generator 内部的 try/catch
- result.done 为 true 时,返回最终 value(作为 Promise resolve 的结果)
这样写语义清晰,天然支持链式处理和错误冒泡,但要求环境支持 Promise。
两者共通点:执行器必须递归驱动,不能靠手动 next
无论用哪种,手动调用 next() 都无法自动衔接异步结果。执行器本质是一个“状态机调度器”:
- 它持有迭代器引用,控制暂停/恢复节奏
- 它把异步完成后的数据,精准塞回 Generator 的 yield 表达式左侧变量
- 它统一处理成功路径和失败路径,避免错误丢失
像 koa1 的 co 库、早期 Babel 的 regenerator-runtime,都是这类执行器的成熟实现。
注意:async/await 其实是 Promise + Generator 的语法糖
现代 async 函数在底层仍复用了 Generator 的暂停/恢复能力(V8 引擎中由隐藏的 Generator + 自动 runner 实现)。写一个 async 函数,等价于手写 Generator + Promise 执行器,只是省去了显式定义和调用 runner 的步骤。
所以理解 Thunk/Promise 如何配合 Generator,不只是为了写旧代码,更是看清 JavaScript 异步演进的主干脉络。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











