如何利用 V8 的内联展开机制优化高频调用的小型纯函数的执行堆栈开销

V8仅内联无副作用、控制流可预测且AST平坦的小型纯函数；add因无闭包、无动态绑定等被内联，而computeWithSideEffect含try/catch致控制流不可推导，故不内联。

V8 会自动对满足条件的小型纯函数做内联展开，前提是它能确信该函数没有副作用、控制流可预测、且 AST 结构足够平坦。盲目压缩行数或拆分函数反而破坏内联机会。

为什么 add 被内联而 computeWithSideEffect 不被内联

V8 的内联决策不看“是否高频”，而看“能否安全替换”。add 这类函数被内联，是因为它：无闭包捕获、无 this 动态绑定、无 arguments、无 try/catch、无 eval、返回值只依赖参数。而 computeWithSideEffect 只要含任意一个 try/catch 块，V8 就标记为 not inlineable: contains try/catch 并跳过——因为异常路径让控制流不可静态推导，逃逸分析和类型特化无法进行。

• 常见错误现象：--trace-inlining 输出中出现 not inlineable: too big for inlining (size=124) 或 contains eval
• 使用场景：循环体内、事件回调、数学工具函数（如 clamp、lerp）
• 性能影响：未内联时每次调用新增栈帧 + IC 查找开销；内联后 TurboFan 可进一步做常量折叠、死代码消除

如何验证函数是否真的被内联了

光看代码结构不够，必须实测。启动 Node.js 时加 --trace-inlining 是最直接方式：

node --trace-inlining script.js

输出类似 [Inlining] add at line 5: inlined into compute 才算成功。若看到 not inlineable 提示，就说明 V8 主动放弃了。

• 浏览器环境可用 %OptimizeFunctionOnNextCall(func)（仅限开启 chrome://flags/#enable-webassembly-simd 的 DevTools）强制触发优化，再配合 --trace-inlining
• 更底层验证：加 --print-opt-code，搜索汇编输出里是否已把 add 的逻辑“展开”进调用方的机器码段
• 避免误判：不要只看函数体行数——一个 8 行但含 3 层 for + arguments.callee 的函数，V8 一定拒之门外

哪些写法会悄悄破坏内联机会

看似无害的语法糖，可能让 AST 复杂度超标，导致 V8 放弃内联：

• 用剩余参数代替固定参数：function sum(...nums) { return nums.reduce((a, b) => a + b, 0); } → nums 是 Array-like，V8 不信任其结构，拒绝内联；改用 function sum(a, b, c) 更稳妥
• 访问 this 或 arguments：哪怕只是读取，也会触发动态作用域分析，中断内联流程
• 闭包捕获外层变量：const factor = 2; const scale = x => x * factor; → 捕获 factor 让函数不再“纯”，降低内联优先级
• 参数类型飘忽：同一函数反复传 number 和 string，触发反优化（deoptimize），TurboFan 会回退并停用内联

要不要手动拆分热函数来“帮助”V8

不需要，而且大概率起反作用。把一个本可内联的 30 行逻辑硬拆成三个 10 行函数，会引入额外间接调用、栈帧、IC 失效风险。V8 关注的是单个函数的“可预测性”，不是“是否短”。

• 真正有效的做法是：用 const 声明局部变量、固定参数类型倾向（如始终传 number）、移除 try/catch、避免 eval 和 with
• 复杂点在于：内联与否是 TurboFan 在运行时根据 feedback 动态决定的，同一个函数在不同执行路径下可能有时内联、有时不内联
• 最容易被忽略的地方：你以为删掉 console.log 就没副作用？错——只要函数体里有对全局对象的写操作（包括 performance.now() 这种看似只读的调用），V8 都可能保守判定为“有潜在副作用”而放弃内联