“热循环别用 for-of更别解构老老实实写for (let i0;ilen;i)”——这条经验法则在前端圈流传甚广几乎每次 Code Review 都能撞见。可它到底是从哪来的我在一台机器上把三种写法、三种数组规模、三种元素类型全跑了一遍结果有点打脸同一段for (const {id,value} of arr)在 1 万长度下比经典 for 慢 46 倍放到 100 万长度却只差不到 4%。结论不是“谁快谁慢”而是那条法则本身建立在会撒谎的微基准之上。背景为什么这条法则还在流传循环是前端最高频的代码形态列表渲染、数据聚合、数组清洗几乎处处是它。早年的 V8以及更早的引擎里for...of因为要创建数组迭代器、逐次调用.next()确实比索引循环慢一截解构又要额外分配绑定。于是“for-of 慢”被写进无数博客和 lint 规则成了默认直觉。但 2026 年的 V8Node 22 自带 V8 12.x早已不是十年前的引擎。真正的问题是绝大多数人验证这个说法时用的是“循环 100 个数”的草稿箱代码。本文要证明的核心论点是——小数组微基准测出来的“慢”和真实工程里的“慢”根本不是一回事。解剖V8 是怎么“吃掉” for-of 的要读懂后面的数字得先知道 V8 不是“编译一次就完事”它分层Ignition解释器→ Sparkplug基线 JIT→ Maglev → TurboFan优化 JIT代码越热越往高层走机器码越激进。内联缓存IC每个属性读取、每次函数调用都记录“上次见过什么形状”下次命中就走快路径命中不了就退化monomorphic → polymorphic → megamorphic。元素类型elements kind数组是PACKED_ELEMENTS无空洞还是HOLEY_ELEMENTS有delete/空洞决定读取走不走快路径。这三件事叠加意味着一段循环在小数据、冷启动、形状多变时测到的往往是“V8 还在学习”的代价而不是循环本身的代价。分层的for-of迭代器开销在冷代码里占比很高一旦 TurboFan 认出“这就是个数组遍历”就会把迭代器大部分消除掉——这正是后面规模一变、结论就翻盘的根因。图1左为 V8 的分层编译管线越热越激进右为数组元素类型有无空洞决定读取是否走快路径。两者共同决定了“同一段 for-of 在不同规模下表现天差地别”。实证同一台机器、三种规模、三种写法的真实数字测试环境Node v22.22.2V8 12.x每项独立函数独立 IC 站点、各自热身后再取中位数累加器落到一个SINK变量防止死代码消除。写法对比classicfor缓存长度读两字段、forOf直接for...of读两字段、destructurefor (const {id,value} of arr)。元素形状分narrow2 字段全读、wide4 字段只读 2、holey中间delete一个元素。# 复现进入 bench 目录用 Node 22 直接跑 node bench.mjs # 输出 1万/10万/100万 × narrow/wide/holey 的中位吞吐(百万次/秒)与相对值 node coldhot.mjs # 单独验证 1万规模下 warmup 拉满后比值是否变化先看稳态10 万、100 万规模中位数相对 classic 1.00规模形状classicforOfdestructure10 万narrow1.000.970.9710 万wide1.000.990.9810 万holey1.000.990.99100 万narrow1.001.041.04100 万wide1.001.011.02100 万holey1.001.031.04在真实规模下三种写法差异全部落在 4% 以内。for-of不慢解构也不慢——TurboFan 把那个{id,value}元组在热循环里优化掉了。形状读 2 字段还是 4 字段没有影响单个空洞holey对“已存在元素”的读取也没有可测惩罚。图2100 万规模下 classic / forOf / destructure 的相对吞吐classic1.00。三者几乎重叠证明 packed 数组上 for-of 与解构均被编译成接近经典 for 的机器码。反直觉点小数组上的 5.7 倍是怎么来的现在看 1 万规模narrowclassic 1.00、forOf 0.25、destructure 0.25——for-of 家族看起来比经典 for 慢约 4 倍。更诡异的是我把coldhot.mjs的预热次数从 10 一路拉到 800forOf的比值稳定在约 5.7× 慢热身拉满也救不回来destructure的比值在5.8× → 11.2× → 1.0×之间剧烈抖动。这恰恰暴露了微基准的两个经典陷阱摊销假象for-of每次调用都要分配一个数组迭代器对象这是一笔“与长度无关的固定开销”。当循环体本身只要遍历 1 万个极简元素时这笔固定开销在总时间里的占比被放大比值就炸成 46 倍放到 100 万固定开销被摊薄到忽略不计比值立刻回归 1 附近。内联缓存/反优化抖动destructure比值随热身剧烈跳变是 V8 在“微小热循环”上反复 tier-up / deopt 的典型产物——你测到的不是循环是引擎的犹豫。换句话说“for-of 慢 5.7 倍”这个结论在 1 万规模上是真的但它衡量的是测量噪声和固定开销不是你工程里热循环的真实成本。图3左为 for-of 在 1 万规模下随 warmup 稳定保持约 5.7× 慢固定开销摊销假象右为 destructure 比值随热身在 5.8×→11.2×→1.0× 间抖动是 IC/deopt 抖动的直接证据。局限我测了什么、没测什么只在Node 22 / V8 12.x上验证SpiderMonkeyFirefox、JavaScriptCoreSafari/iOS未覆盖结论不能直接外推到浏览器——尤其 iOS 强制 WebKit若你的流量大量来自 Safari应在真机复测。数组元素是对象且字段同形状同 hidden class未测 TypedArray、未测“字段形状混杂”导致的 polymorphic IC 退化那种场景下经典 for 与 for-of 的差距可能重新拉开。只测了读纯写入、就地push、链式map/filter不在本次范围。holey仅制造了一个空洞未压测“大量稀疏”场景——真实业务里更该警惕的是delete之后整条数组退化带来的写入与遍历空洞成本而非单元素读取。结论与下一步一句话方法论现代 V8 下packed 数组的for-of和for (const {a,b} of arr)解构与经典for在稳态下是同一量级差异 4%别再为“性能”在热循环里禁用它们真正该戒掉的是“用小数组微基准决定循环写法”——要测就热身后在真实规模上测。只有当你确认某段循环是剖析器里反复命中的热点、且要挤最后 1% 时才值得回退到for (let i0,llen;il;i)。开源地址矩阵门户https://github.com/wangzifan396-wzf/WB单文件工具聚合器https://github.com/wangzifan396-wzf/nano-workbenchGitHub 组织主页https://github.com/wangzifan396-wzf 小数组慢 5.7 倍、百万级只差 4%：for-of 解构循环到底该不该用的实测复盘
“热循环别用 for-of更别解构老老实实写for (let i0;ilen;i)”——这条经验法则在前端圈流传甚广几乎每次 Code Review 都能撞见。可它到底是从哪来的我在一台机器上把三种写法、三种数组规模、三种元素类型全跑了一遍结果有点打脸同一段for (const {id,value} of arr)在 1 万长度下比经典 for 慢 46 倍放到 100 万长度却只差不到 4%。结论不是“谁快谁慢”而是那条法则本身建立在会撒谎的微基准之上。背景为什么这条法则还在流传循环是前端最高频的代码形态列表渲染、数据聚合、数组清洗几乎处处是它。早年的 V8以及更早的引擎里for...of因为要创建数组迭代器、逐次调用.next()确实比索引循环慢一截解构又要额外分配绑定。于是“for-of 慢”被写进无数博客和 lint 规则成了默认直觉。但 2026 年的 V8Node 22 自带 V8 12.x早已不是十年前的引擎。真正的问题是绝大多数人验证这个说法时用的是“循环 100 个数”的草稿箱代码。本文要证明的核心论点是——小数组微基准测出来的“慢”和真实工程里的“慢”根本不是一回事。解剖V8 是怎么“吃掉” for-of 的要读懂后面的数字得先知道 V8 不是“编译一次就完事”它分层Ignition解释器→ Sparkplug基线 JIT→ Maglev → TurboFan优化 JIT代码越热越往高层走机器码越激进。内联缓存IC每个属性读取、每次函数调用都记录“上次见过什么形状”下次命中就走快路径命中不了就退化monomorphic → polymorphic → megamorphic。元素类型elements kind数组是PACKED_ELEMENTS无空洞还是HOLEY_ELEMENTS有delete/空洞决定读取走不走快路径。这三件事叠加意味着一段循环在小数据、冷启动、形状多变时测到的往往是“V8 还在学习”的代价而不是循环本身的代价。分层的for-of迭代器开销在冷代码里占比很高一旦 TurboFan 认出“这就是个数组遍历”就会把迭代器大部分消除掉——这正是后面规模一变、结论就翻盘的根因。图1左为 V8 的分层编译管线越热越激进右为数组元素类型有无空洞决定读取是否走快路径。两者共同决定了“同一段 for-of 在不同规模下表现天差地别”。实证同一台机器、三种规模、三种写法的真实数字测试环境Node v22.22.2V8 12.x每项独立函数独立 IC 站点、各自热身后再取中位数累加器落到一个SINK变量防止死代码消除。写法对比classicfor缓存长度读两字段、forOf直接for...of读两字段、destructurefor (const {id,value} of arr)。元素形状分narrow2 字段全读、wide4 字段只读 2、holey中间delete一个元素。# 复现进入 bench 目录用 Node 22 直接跑 node bench.mjs # 输出 1万/10万/100万 × narrow/wide/holey 的中位吞吐(百万次/秒)与相对值 node coldhot.mjs # 单独验证 1万规模下 warmup 拉满后比值是否变化先看稳态10 万、100 万规模中位数相对 classic 1.00规模形状classicforOfdestructure10 万narrow1.000.970.9710 万wide1.000.990.9810 万holey1.000.990.99100 万narrow1.001.041.04100 万wide1.001.011.02100 万holey1.001.031.04在真实规模下三种写法差异全部落在 4% 以内。for-of不慢解构也不慢——TurboFan 把那个{id,value}元组在热循环里优化掉了。形状读 2 字段还是 4 字段没有影响单个空洞holey对“已存在元素”的读取也没有可测惩罚。图2100 万规模下 classic / forOf / destructure 的相对吞吐classic1.00。三者几乎重叠证明 packed 数组上 for-of 与解构均被编译成接近经典 for 的机器码。反直觉点小数组上的 5.7 倍是怎么来的现在看 1 万规模narrowclassic 1.00、forOf 0.25、destructure 0.25——for-of 家族看起来比经典 for 慢约 4 倍。更诡异的是我把coldhot.mjs的预热次数从 10 一路拉到 800forOf的比值稳定在约 5.7× 慢热身拉满也救不回来destructure的比值在5.8× → 11.2× → 1.0×之间剧烈抖动。这恰恰暴露了微基准的两个经典陷阱摊销假象for-of每次调用都要分配一个数组迭代器对象这是一笔“与长度无关的固定开销”。当循环体本身只要遍历 1 万个极简元素时这笔固定开销在总时间里的占比被放大比值就炸成 46 倍放到 100 万固定开销被摊薄到忽略不计比值立刻回归 1 附近。内联缓存/反优化抖动destructure比值随热身剧烈跳变是 V8 在“微小热循环”上反复 tier-up / deopt 的典型产物——你测到的不是循环是引擎的犹豫。换句话说“for-of 慢 5.7 倍”这个结论在 1 万规模上是真的但它衡量的是测量噪声和固定开销不是你工程里热循环的真实成本。图3左为 for-of 在 1 万规模下随 warmup 稳定保持约 5.7× 慢固定开销摊销假象右为 destructure 比值随热身在 5.8×→11.2×→1.0× 间抖动是 IC/deopt 抖动的直接证据。局限我测了什么、没测什么只在Node 22 / V8 12.x上验证SpiderMonkeyFirefox、JavaScriptCoreSafari/iOS未覆盖结论不能直接外推到浏览器——尤其 iOS 强制 WebKit若你的流量大量来自 Safari应在真机复测。数组元素是对象且字段同形状同 hidden class未测 TypedArray、未测“字段形状混杂”导致的 polymorphic IC 退化那种场景下经典 for 与 for-of 的差距可能重新拉开。只测了读纯写入、就地push、链式map/filter不在本次范围。holey仅制造了一个空洞未压测“大量稀疏”场景——真实业务里更该警惕的是delete之后整条数组退化带来的写入与遍历空洞成本而非单元素读取。结论与下一步一句话方法论现代 V8 下packed 数组的for-of和for (const {a,b} of arr)解构与经典for在稳态下是同一量级差异 4%别再为“性能”在热循环里禁用它们真正该戒掉的是“用小数组微基准决定循环写法”——要测就热身后在真实规模上测。只有当你确认某段循环是剖析器里反复命中的热点、且要挤最后 1% 时才值得回退到for (let i0,llen;il;i)。开源地址矩阵门户https://github.com/wangzifan396-wzf/WB单文件工具聚合器https://github.com/wangzifan396-wzf/nano-workbenchGitHub 组织主页https://github.com/wangzifan396-wzf