迭代器与生成器

是什么，为什么存在

迭代器（iterator）是一个有状态对象，它的 next() 方法每次描述序列中的下一步。 可迭代对象（iterable）则实现 [Symbol.iterator]()，并用该方法提供迭代器。 两者分工明确：前者保存一次遍历的位置，后者定义怎样开始一次遍历。

JavaScript 的数组、字符串、Map 和 Set 结构不同，却都能被 for...of、数组解构和展开语法消费。 原因不是这些语法分别了解每种容器，而是生产者和消费者共同遵守迭代协议（iteration protocol）。 自定义集合只要提供同样的入口，也能接入这些语言结构。

生成器函数（generator function）是编写迭代器的语言级工具。 调用 function* 不会立即运行函数体，而是返回生成器对象；后续 next() 调用让函数运行到下一个 yield 并暂停。 局部变量和执行位置在暂停期间保留，因此代码可以按需生产序列，而不必先构造完整数组。

同步迭代适合已经可以立即计算的值。 如果每一步都要等待网络或定时器，应使用异步迭代器，而不是让同步迭代器产出一串未处理的 Promise。 这部分语义由相关主题 javascript/async-iterators 单独说明。

两份协议，三个角色

一个 iterator result 是普通对象。 当 done 为假时，value 是本步产出的值；当 done 为真时，序列已结束，value 可以保存最终返回值，也可以省略。 消费者必须读取 done，不能把值为 undefined 当作结束信号，因为 undefined 本身可以是合法产出。

可迭代对象的 [Symbol.iterator]() 必须返回对象。 该对象的 next() 也必须返回对象，否则协议消费者会抛出 TypeError。 一个普通对象仅仅拥有 next() 还只是迭代器，不一定能直接交给 for...of。

同一协议服务于多种消费者，但消费方式不同：

• for...of 每轮请求一个值，并允许用 break 提前结束。
• 数组解构按模式位置请求值，剩余元素会把余下序列全部收集成数组。
• [...iterable] 和 Array.from(iterable) 会一直请求到 done 为真，并把结果物化。
• yield* iterable 在一个生成器内部把请求转交给另一个可迭代对象。

工作原理

一次迭代的步骤

消费者先读取可迭代对象的 [Symbol.iterator] 方法，调用它并保存返回的迭代器。 随后，消费者重复调用 next()。 每个结果对象让消费者获得一个值或确认迭代完成。

done 被省略时会按假值处理，因此产出步骤通常可以只返回 { value }。 明确写出 { value, done: false } 更容易审查，完成步骤则通常返回 { done: true }。 协议不要求 value 具有特定类型，也不要求序列长度已知。

迭代器保存游标、队列或其他进度状态。 如果一个集合打算支持相互独立的两次遍历，每次调用 [Symbol.iterator]() 就应创建独立状态。 生成器方法天然适合这种实现，因为每次调用都会得到新的生成器对象。

生成器的暂停状态

生成器对象同时是迭代器和可迭代对象。 它的 [Symbol.iterator]() 返回自身，所以可以先手动调用 next()，再用 for...of 继续消费同一份状态。 这也意味着传播的是当前游标，而不是可重复执行的序列描述。

第一次调用 next(argument) 时，实参会被忽略，因为函数还没有暂停在可接收值的 yield 表达式上。 生成器运行到 yield expression 后，把表达式右侧的值交给调用方并暂停。 下一次 next(value) 会让上一个 yield 表达式求值为传入的 value。

return value 会结束生成器，并产生 { value, done: true }。 for...of、展开语法和 Array.from() 只收集 done 为假时的值，因此不会收集这个最终返回值。 只有手动读取最后一次 next() 的调用方，或者使用 yield* 的外层生成器，才能直接取得它。

生成器的典型状态变化如下：

1. 调用生成器函数，创建尚未开始的生成器对象。
2. 调用 next()，执行函数体并在 yield 处暂停。
3. 再次调用 next(value)，把值送回暂停点并继续运行。
4. 执行 return、抵达函数末尾或传播未捕获异常，生成器结束。

消费者负责推进与关闭

惰性只表示生产者按请求工作，并不保证调用方只请求少量值。 for...of 可以逐步处理并提前退出，而展开或剩余解构会急切地把余下内容全部放进内存。 选择消费者时，需要同时考虑序列是否有限以及结果是否必须物化。

当 for...of 因 break、return 或异常提前离开时，会对仍未完成的迭代器执行关闭流程。 如果迭代器提供 return()，消费者会调用它。 生成器的 return() 会恢复执行清理路径，因此包围 yield 的 finally 可以在提前退出时运行。

协议只提供清理机会，不会猜测资源所有权。 自定义手写迭代器若持有文件句柄、锁或订阅，就要实现合适的 return()；若没有该方法，退出循环无法通知它释放资源。 对资源边界应编写提前退出测试，而不只是测试完整消费。

示例

可重复遍历的范围

StepRange 是可迭代对象，而不是共享游标。 生成器方法 *[Symbol.iterator]() 每次创建新状态，所以同一个范围可以完整展开两次。

for...of 隐式调用这个方法，展开语法也一样。 私有字段属于范围描述；循环变量属于本次调用产生的生成器。 两种状态分开后，并行消费者不会争用同一个位置。

构造函数拒绝非正步长，因为当前循环条件只描述递增范围。 如果接口还要支持递减范围，应明确验证方向并选择对应的终止条件，不能只删除这项检查。

惰性筛选与提前清理

下一个例子把数组包装成会记录读取动作的源生成器，再由另一个生成器选取前两个已批准订单。 第四条订单没有被读取，说明生产过程确实由下游请求推进。

const orders = [
  { id: "A-17", status: "pending" },
  { id: "B-04", status: "approved" },
  { id: "C-22", status: "approved" },
  { id: "D-09", status: "approved" },
];

function* orderStream(rows) {
  try {
    for (const row of rows) {
      console.log(`read ${row.id}`);
      yield row;
    }
  } finally {
    console.log("source closed");
  }
}

function* firstApproved(rows, limit) {
  let found = 0;
  for (const row of rows) {
    if (row.status !== "approved") continue;
    yield row.id;
    found += 1;
    if (found === limit) return;
  }
}

const selected = firstApproved(orderStream(orders), 2);
console.log(JSON.stringify([...selected]));

read A-17
read B-04
read C-22
source closed
["B-04","C-22"]

firstApproved 在达到上限后从内部 for...of 返回。 该循环关闭仍处于暂停状态的 orderStream，于是源生成器进入 finally 并输出 source closed。 这不是垃圾回收效果，而是同步控制流的一部分。

最外层仍然使用展开语法，但它展开的是明确受限的 selected。 直接展开没有上限的源会失去提前停止带来的优势。

用 next(value) 双向通信

生成器不仅能产出值，还能在暂停点接收值。 这种接口要求调用方和生成器共享一套消息顺序，因此适合受控的状态机，不适合隐藏在普通集合遍历里。

function* reviewConversation() {
  const reviewer = yield { type: "request", order: "A-17" };

  try {
    const decision = yield { type: "review", reviewer };
    return { type: "result", decision };
  } finally {
    console.log("conversation closed");
  }
}

const flow = reviewConversation();
console.log(JSON.stringify(flow.next("ignored")));
console.log(JSON.stringify(flow.next("Mina")));
console.log(JSON.stringify(flow.next("approve")));

{"value":{"type":"request","order":"A-17"},"done":false}
{"value":{"type":"review","reviewer":"Mina"},"done":false}
conversation closed
{"value":{"type":"result","decision":"approve"},"done":true}

第一步中的 ignored 没有接收点，所以不会赋给 reviewer。 第二次调用把 Mina 送入第一个 yield，第三次调用再把 approve 送入第二个 yield。 每次返回的 done 明确表示消息是中间产出还是最终结果。

若调用方改用 for...of，只能拿到两个 yield 产生的对象，拿不到 return 的结果。 需要最终结果和双向输入时，应保留生成器对象并显式驱动协议。

用 yield* 组合遍历

yield* 接受任何可迭代对象，不只接受生成器。 递归目录遍历可以把子树的所有产出委托给递归调用，同时保持一个平坦的外部序列。

function* walkFiles(entry, parent = "") {
  const path = parent ? `${parent}/${entry.name}` : entry.name;

  if (entry.type === "file") {
    yield path;
    return;
  }

  for (const child of entry.children) {
    yield* walkFiles(child, path);
  }
}

const project = {
  name: "app",
  type: "directory",
  children: [
    { name: "index.js", type: "file" },
    {
      name: "lib",
      type: "directory",
      children: [{ name: "parse.js", type: "file" }],
    },
  ],
};

console.log(JSON.stringify([...walkFiles(project)]));

["app/index.js","app/lib/parse.js"]

调用方只看到路径序列，不需要知道某个值来自哪一层生成器。 外层消费者若提前关闭遍历，关闭请求也会沿当前的委托链传播。

这里的数据树有限，所以展开结果是安全的。 面对文件系统或用户提供的树，还应决定怎样处理环、极深递归和读取错误；迭代协议本身不会解决这些输入问题。

陷阱

协议代码的错误通常不在循环语法，而在状态所有权、消费边界和清理契约。 以下问题尤其容易藏在看似简洁的生成代码中。

修复： 需要重复遍历时保存生成器函数或 iterable，并在每次消费时调用它来创建新 iterator。 如果 API 有意接受单次数据源，应在类型、参数名和测试中明确这一所有权约束。

修复： 始终检查 iterator result 的 done。 手写消费者还要验证 next() 的返回值是对象，并决定异常应在哪个边界传播或转换。

修复： 在物化前用业务上限截断序列，或用 for...of 边处理边退出。 上限应来自输入契约，不能靠“数据通常很小”这一假设。

修复： 用无实参的 next() 启动生成器，再按协议发送后续值。 若消息顺序对调用方不直观，应改用具名方法或显式状态对象，而不是暴露双向生成器。

修复： 为可提前结束的资源迭代器实现幂等 return()，并测试完整消费、break 和消费方抛错三条路径。 生成器应把释放动作放进包围 yield 的 finally，但从未启动的生成器不会执行其函数体或清理块。

延伸阅读

• ECMAScript 语言规范：Iterator Objects
• ECMAScript 语言规范：Generator Objects
• MDN：迭代协议
• MDN：function* 声明