Symbol.asyncIterator要求对象返回符合协议的异步迭代器，即next()必须返回Promise，且需正确管理状态、支持多次调用及终止条件。
Symbol.asyncIterator 是 JavaScript 中让对象支持 for await...of 的关键。它不是“加个属性就能用”，而是必须返回一个符合异步迭代器协议的对象——即带 next() 方法、且该方法返回 Promise 的对象。
为什么直接 return { next: () => Promise.resolve(...) } 还是报错？
常见错误是只实现了 next()，但没处理 done 和 value 的结构，或忘了 next() 必须可多次调用并按需推进状态。浏览器/Node.js 在执行 for await...of 时会反复调用 next()，直到 done: true。
-
next()必须返回Promise，不能只 resolvevalue - 若
done永远为false，循环永不终止 - 若
next()每次都返回相同 Promise（比如缓存了结果），就无法实现“逐次异步拉取”语义
如何手动实现一个带延迟的异步迭代器？
适合模拟 API 分页、流式读取文件等场景。核心是把迭代状态（如当前索引、是否结束）存在闭包或实例属性里：
const asyncCounter = {
from: 0,
to: 3,
[Symbol.asyncIterator]() {
let i = this.from;
return {
next: () => {
if (i <= this.to) {
// 模拟异步操作（如 fetch）
return Promise.resolve({ value: i++, done: false });
}
return Promise.resolve({ value: undefined, done: true });
}
};
}
};
// 使用
(async () => {
for await (const num of asyncCounter) {
console.log(num); // 0, 1, 2, 3
}
})();
在类中实现时，this 指向和状态管理要注意什么？
类方法中若用箭头函数写 next，this 会绑定到实例，方便维护内部状态；但若用普通函数，需确保 next 被调用时 this 不丢失（bind 或用实例属性存状态更稳妥）。
立即学习“前端免费学习笔记（深入）”；
- 避免在
[Symbol.asyncIterator]()工厂函数里直接修改this状态（如this.i++），因为多次遍历会互相干扰 - 推荐在每次调用
[Symbol.asyncIterator]()时新建一个独立的迭代器对象，各自持有自己的状态 - 若需复用逻辑，把迭代器逻辑抽成工厂函数，例如：
createAsyncIterator(items)
Node.js ReadableStream 与 Symbol.asyncIterator 的关系
Node.js v10+ 的 ReadableStream（包括 fs.createReadStream）原生实现了 Symbol.asyncIterator，所以能直接 for await...of。但注意：它默认以 buffer 形式吐出数据块，不是按行或按字符；若需按行处理，得自己封装或用 readline.createInterface()。
- 原生支持 ≠ 自动分块合理：大文件一次
next()可能返回几 MB 的Buffer - 不支持
break或return后自动destroy()，需手动调用stream.destroy()防止内存泄漏 - 某些旧库（如早期
pg查询结果）需手动挂载Symbol.asyncIterator才能用于for await
真正难的不是写对语法，而是让 next() 的每次调用既反映真实异步进度，又不因重复遍历、中断或并发而错乱状态。多数 bug 出现在状态初始化时机和 done 判定边界上。
