不能利用 new.target 消除迭代链断层——其真实成因是混淆重命名、裸对象返回、转译擦除或手动剥离 Symbol.iterator；new.target 仅判断 new 调用，不参与迭代器注入或原型修复。
不能利用 new.target 消除迭代链断层——这个前提本身不成立。
迭代链断层的真实成因
所谓“迭代链断层”，通常指对象无法被 for...of 正常遍历，或 Symbol.iterator 缺失、返回无效迭代器。其根源与 new.target 无关，而是：
- 混淆工具（如 Terser）重命名了类名或方法名，导致子类中
items()或[Symbol.iterator]被破坏或丢失 - 工厂函数直接返回裸对象（
{}），未挂载迭代器，也未调用super() - Babel 转译时对
Symbol.iterator的静态定义处理不当，尤其在继承链中被擦除或覆盖 - 手动赋值
obj[Symbol.iterator] = null或使用Object.create(null)初始化对象，彻底剥离内置属性
new.target 的实际作用边界
new.target 是一个运行时元属性，仅用于判断函数是否被 new 调用，它：
- 不参与对象属性的定义或注入，无法自动添加
Symbol.iterator - 不干预原型链构建，也不能修复已丢失的迭代器接口
- 不感知 Symbol 属性是否存在，更不会在构造时“补全”缺失的迭代协议
真正有效的修复方向
应聚焦构建阶段保语义、运行时补契约、测试层验行为：
- 在打包配置中启用
keep_fnames: true和reservedNames: ['IteratorBase', 'items']，防止关键方法名被混淆 - 对已知需迭代的对象类型，在创建后主动绑定：
Object.defineProperty(obj, Symbol.iterator, { value: () => obj.items()[Symbol.iterator](), enumerable: false }) - 用
Array.from(obj)或obj[Symbol.iterator]?.() instanceof Iterator替代简单typeof obj[Symbol.iterator] === 'function'做运行时校验 - 在 ESLint 中启用
no-prototype-builtins并自定义规则，拦截Object.create(null)在迭代容器场景中的误用
如何快速验证迭代链是否完整
不要只检查 obj[Symbol.iterator] 是否存在，而要走通整个链路：
- 执行
const it = obj[Symbol.iterator](); it.next()，确认不抛错且返回符合迭代器协议的对象 - 在控制台输入
for (const x of obj) break，观察是否报TypeError: obj is not iterable - 检查
Object.getPrototypeOf(obj)及其向上链，确认未意外指向null或Object.prototype（除非设计如此）
