async/await是generator+promise的语法糖，无需手动组合；真正需用generator的场景是需中断、回退、复用状态或逐条消费超大数据流；异步生成器（async function*）结合for await...of才是处理复杂异步流的推荐方式。
async/await 本身已是 Generator + Promise 的语法糖，不再需要手动组合两者来实现异步流逻辑。真正需要结合 Generator 的场景，是当标准 async/await 无法满足特定控制需求时——比如需中断、回退、复用状态、或逐条消费超大数据流（如分页遍历、实时事件流）。
Generator 不是 async/await 的“搭档”，而是它的底层基础
现代 JavaScript 中，async 函数在编译或运行时会被引擎转译为类似 Generator 的结构：每个 await 对应一个 yield，整个函数被包裹进自动执行器（如 Promise 链驱动的 next 调用）。你写的：
async function loadAll() {
const a = await fetch('/a');
const b = await fetch('/b');
return [a, b];
}
本质上等价于一个被自动驱动的 Generator：
function* loadAllGen() {
const a = yield fetch('/a');
const b = yield fetch('/b');
return [a, b];
}
但区别在于：前者由语言原生支持自动调度；后者需你手写执行器（如 co 库或自定义 run 函数）来处理 Promise、传递结果、捕获错误。
何时该主动用 Generator 处理异步流？
不是为了替代 async/await，而是解决它不擅长的问题：
- 内存敏感的流式消费：比如拉取 10 万条分页数据，你不需要全量存入数组，而希望“拉一页、处理一页、释放一页”。这时用 异步生成器函数（async function*） + for await...of 是最自然的选择
- 可暂停/恢复的状态机：例如表单多步骤提交，每步可被用户中断、跳转、重试，且中间状态需保留（如已填字段、临时上传凭证）
- 协程式协作调度：多个异步任务需按优先级抢占执行权，或根据响应动态决定下一步 yield 哪个请求（如 A 请求返回后才决定是否发 B 或 C）
- 调试与可观测性：手动控制每一步 next()，便于打点、埋点、日志插桩，甚至注入模拟延迟或错误
异步生成器（Async Generator）才是实用接口
ES2018 起支持 async function*，它返回异步迭代器，天然适配 for await...of，无需手写执行器：
async function* paginate(url, limit = 50) {
let cursor = null;
while (true) {
const res = await fetch(`${url}?limit=${limit}&cursor=${cursor || ''}`);
const { data, next_cursor } = await res.json();
for (const item of data) yield item;
if (!next_cursor) break;
cursor = next_cursor;
}
}
<p>// 消费时自动按需拉取，内存只留当前项
for await (const record of paginate('/api/items')) {
await saveToDB(record); // 每条独立处理，失败不影响后续
}</p>
这种写法兼顾了 async/await 的简洁性与 Generator 的流控能力，是当前处理复杂异步流的推荐方式。
别硬套 Generator + 手动执行器去模拟 async/await
除非你在写底层库（如测试框架的 step runner、低代码引擎的流程编排器），否则不建议：
- 用
function*写业务逻辑再配 co 或自研 run 函数 - 把所有 await 替换为 yield Promise，并自己 resolve/reject 传值
- 为简单 API 调用链强行引入迭代器抽象
这类做法增加心智负担，削弱可读性，且错误处理、堆栈追踪、调试支持远不如原生 async/await。
