for (const [i, v] of arr.entries()) 最优：惰性迭代、零冗余解构、引擎深度优化，性能接近传统 for 循环，远超手动索引或对象解构。
Array.prototype.entries() 返回的迭代器本身是惰性求值的，不生成新数组，只在每次 for...of 迭代时按需调用 next()，产出一个形如 [index, value] 的二元数组。解构性能的关键不在“能不能拆”，而在于“怎么拆最轻量”。
解构本身几乎没有运行时开销
JavaScript 引擎对数组解构 const [i, v] of arr.entries() 做了深度优化：它不是先创建完整对象再提取属性，而是直接从迭代器返回的内部数组中读取第 0 和第 1 项。这个过程和手动写 entry[0]、entry[1] 在 V8 等现代引擎中几乎等价，没有额外内存分配或属性查找成本。
真正影响性能的其实是解构方式的选择
- ✅ 推荐：
for (const [i, v] of arr.entries())—— 一次解构到位，语义清晰，引擎可静态分析，无冗余操作 - ⚠️ 不推荐：
for (const entry of arr.entries()) { const i = entry[0]; const v = entry[1]; }—— 多出两行赋值，且entry变量本身可能触发临时绑定开销（尤其在严格模式或闭包中） - ❌ 错误：
for (const {0: i, 1: v} of arr.entries())或for (const {index, value} of ...)—— 语法虽合法（对象解构支持数字键），但 entries 不返回对象，实际会得到undefined；若强行用，还多一层属性访问逻辑，纯属误导
稀疏数组和空位不影响解构效率
即使数组含空位（如 [,, 'c']），entries() 仍按索引顺序产出 [0, empty]、[1, empty]、[2, 'c']。解构 [i, v] 时，v 被设为 undefined，这个行为由引擎底层统一处理，不引入分支判断或类型检查拖慢循环。
和传统 for 循环的性能对比很现实
在百万级元素测试中，for (const [i, v] of arr.entries()) 比 for (let i = 0; i 慢约 5%–15%，差异主要来自迭代器协议调用开销（<code>next() 方法调用、done 判断）。但这点差距在真实业务中通常不可感知——只要单次循环体逻辑不是空操作或超简单计算，瓶颈一定在你的业务代码，而不是解构本身。
所以不必为 entries + 解构纠结性能，它牺牲的那点毫秒，换来了更安全的索引控制、更清晰的意图表达，以及对稀疏数组、原型污染的天然免疫。
