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 都可能保守判定为“有潜在副作用”而放弃内联
