JavaScript Iterator.from怎样把类迭代对象统一转换

把数组、集合和第三方库返回的同步游标交给同一个处理函数时，可以用 Iterator.from(source) 取得带标准迭代器原型的对象。关键在于输入已经符合可迭代协议或同步迭代器协议；只有数字索引和 length 的类数组，需要另行适配。

转换统一的是调用接口，不会复制数据，也不会把已经消耗的游标重新开始。下面以任务编号筛选为例，区分适用对象、收益和迁移代价。

标准入口可复制查阅：

https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-iterator.from

统一入口为何围绕迭代协议设计

数组习惯用 map、filter 组合操作，但一些库只交付 next() 游标。调用方如果先把全部数据收集成数组，才能使用熟悉的方法，就会把“读取接口”和“保存完整结果”混在一起。Iterator.from 提供一个适配位置，后续可以对标准迭代器使用辅助方法。

MDN 将该功能标为 Baseline 2025，并提醒旧设备可能缺少支持。这说明新环境已有使用基础，不能推断所有存量 WebView、服务器运行时或嵌入页面都具备它。对项目的建议是先封装输入，再按实际支持范围采用，而非全局机械替换 Array.from。

区分可迭代对象、迭代器和类数组

先看数据来源的契约。可迭代对象提供 Symbol.iterator，能取得一个游标；同步迭代器提供 next，交付包含 value 和 done 的结果对象；类数组通常只有 length 与索引。三个名称相近，但代表的能力不同。

若一个对象同时提供 Symbol.iterator 和 next，应把前者取得的迭代器看作实际来源。转换也不会预先证明未来每次 next 都符合约定；错误的返回值可能到消费时才暴露。不要用“转换没有立即报错”替代来源契约。

把库提供的游标接入统一调用

假设一个旧组件交付任务编号游标，它不提供 Symbol.iterator，也没有标准辅助方法。下面的工厂每次创建独立位置，next 使用 this 读取状态，能够说明包装器仍依赖原对象。代码为原创语义示例，预期值用于解释，没有声称在当前设备执行。

function createTaskCursor() {
  return {
    ids: [31, 32, 33, 34],
    position: 0,
    next() {
      if (this.position >= this.ids.length) {
        return { done: true, value: undefined };
      }
      return { done: false, value: this.ids[this.position++] };
    }
  };
}

const cursor = createTaskCursor();
const tasks = Iterator.from(cursor);
const evenIds = tasks.filter(id => id % 2 === 0).toArray();
// 依据示例数据，evenIds 应为 [32, 34]。
// cursor 也已被消费，不能再从 31 开始。

这里的收益落在组件集成者身上：上层筛选代码不必分别照顾数组与旧游标。包装器调用底层 next 时保留底层对象作为接收者，所以 position 仍属于 cursor；不要把 next 裸取出来再随意调用。若来源本身已有标准 Iterator 原型，from 可以直接返回它，业务代码不能依赖“必定新建一个对象”。

对于只有索引的短列表，可明确收集一次再取得迭代器：

const legacy = { 0: "draft", 1: "ready", length: 2 };
const normalized = Iterator.from(Array.from(legacy));
// Array.from 在这里完成类数组到数组的适配。

这条路径存在数组分配，不应作为“大数据零拷贝”的宣传例子。若需要按需读取，可为已知、可信的索引数据编写生成器；适配代码必须定义长度、缺项和数据变化的处理规则。

包装之后仍要管理消耗与关闭

同一个游标包装两次不会获得两份数据。两个包装对象可能各不相同，却仍共用同一个底层位置；一个消费者取走的元素，另一个消费者就无法重新取得。需要重复读取时，应保存可重复创建的来源工厂，而非保存消费中的包装器。

function createTaskIterator() {
  return Iterator.from(createTaskCursor());
}

const firstRead = createTaskIterator();
const secondRead = createTaskIterator();
// 两次工厂调用各自创建新的底层游标。

有资源的游标还应定义 return。包装器的 return 会委托来源已有的 return；没有这个方法时，包装器返回完成结果并不等于来源资源获得清理。取消读取的责任需要写在库与调用方的协议里，不能因为使用了标准接口就假定文件、连接或订阅一定被释放。

从局部适配逐步引入项目

先选择一个输入种类明确的工具函数，例如只接收同步任务编号序列的筛选器。把类型约定与兼容分支放在入口，业务层只看到最终结果，避免到处出现检测代码。数组用法本已清楚且规模有限时，继续使用数组方法也合理。

function pickEvenTaskIds(ids) {
  const supported =
    typeof globalThis.Iterator === "function" &&
    typeof globalThis.Iterator.from === "function" &&
    typeof globalThis.Iterator.prototype.filter === "function" &&
    typeof globalThis.Iterator.prototype.toArray === "function";

  if (!supported) {
    // 此函数约定 ids 是可迭代对象；不承诺接收裸 next 游标。
    return Array.from(ids).filter(id => id % 2 === 0);
  }
  return globalThis.Iterator.from(ids)
    .filter(id => id % 2 === 0)
    .toArray();
}

兼容分支特意限定为可迭代对象，因为 Array.from 并不是任意裸 next 游标的通用替代品。若确实要支持第三方游标，应为它单独实现适配并处理提前结束，不要把不支持的输入悄悄转换为空列表。TypeScript 的类型声明可帮助表达约束，但声明或编译通过不代表目标运行时拥有该 API。

采用时关注兼容性和数据契约

决定是否推广时，关注目标设备是否具备所用方法、数据是否只消费一次、来源是否可能无限、异常时谁负责清理。尤其是 toArray 会收集剩余全部数据，无限来源必须先定义合理的读取上限；不能仅凭中间筛选是惰性的，就认为最终内存也有上限。

性能收益取决于原先的中间数组、来源成本与最终结果大小。本文没有基准数据，因此不宣称统一转换必然更快。更稳定的收益是把输入协议放在一处说明，让组件作者、业务调用者和维护者对消费规则有共同认识。

Iterator.from 能直接处理普通对象吗？

普通键值对象需要先明确遍历键、值还是条目，例如选用 Object.entries；不要自动把任意对象解释成某一种业务序列。

为什么再次遍历没有数据？

如果保存的是已消耗的游标，包装不会重置它。重新调用来源工厂，或在业务允许时保存有限结果。

可以用它统一异步接口吗？

这里讨论同步迭代契约。返回 Promise 的 next 不会因此被等待，异步来源应使用匹配的异步迭代入口与消费方式。

参考：ECMAScript Iterator.from 规范、GetIteratorFlattenable 输入规则、MDN Iterator.from 与支持说明。