V8内联函数的关键是安全性而非调用频次：add因纯函数、无副作用、AST简单而被内联；computeWithSideEffect含try/catch、eval或动态绑定等破坏控制流可预测性的结构，导致V8放弃内联。
为什么 add 被内联了，而 computeWithSideEffect 没有？
V8 内联函数不是看“有没有被调用很多次”，而是看“能不能安全地展开”。add 这类纯函数（无副作用、无闭包捕获、无动态作用域引用）结构平坦、AST 节点少，V8 在 TurboFan 阶段能直接把它塞进调用点；而哪怕只有 8 行，只要含 try/catch、eval、this 动态绑定、或访问 arguments，V8 就会放弃内联——因为这些结构破坏了控制流可预测性，无法做逃逸分析和类型特化。
哪些参数和返回值模式更容易触发内联？
内联成功率高度依赖类型稳定性与接口简洁性：
-
function clamp(min, value, max) { return value max ? max : value); }—— 三参数、单返回、全比较分支，V8 很可能内联； -
function process(obj) { return obj?.x ?? 0; }—— 可选链 + 空值合并，触发隐式hasOwnProperty查找，破坏单态 IC，大概率不内联； -
function multiply(a, b) { return a * b; }—— 参数类型倾向明确（尤其在循环中反复传number），配合隐藏类稳定，内联概率高； - 避免
function foo(...args) { return args[0] + args[1]; }：剩余参数让 AST 复杂化，且args是 Array-like 对象，V8 不信任其结构。
怎么确认某个函数真的被内联了？
别猜，用 V8 自带的诊断开关实测：
- 启动 Node.js 时加
--trace-inlining：运行后会在 stdout 输出类似[Inlining] add at line 5: inlined into compute的日志； - 加
--trace-opt可看到更详细的优化决策，比如not inlineable: contains try/catch或too big for inlining (size=124)； - 注意：只对“温热”（执行约 10–100 次）后的函数生效，冷路径不会触发优化编译；
- 浏览器环境可用
%OptimizeFunctionOnNextCall(func)（仅限chrome://flags/#enable-webassembly-simd开启的调试版 DevTools）强制触发，再配合--trace-inlining观察。
拆分函数时最容易忽略的陷阱
把一个 30 行逻辑硬拆成三个 10 行函数，不一定提升性能——反而可能因间接调用、额外栈帧、IC 失效拖慢整体。关键判断点是：
- 是否高频出现在热点路径（如
for循环体、requestAnimationFrame 回调）； - 拆分后每个子函数是否仍满足「纯」+「小 AST」+「固定参数个数」；
- 是否引入了新的闭包捕获（例如把外层变量通过参数传入，比直接访问
const局部变量更易破坏内联）； - 用
console.time+ 实际数据对比：拆分前后的 10 万次调用耗时差是否超过 5%，否则优化无效。
真正影响内联的从来不是行数，而是你写的那几行里有没有让 V8 “不敢信”的东西——比如一行 try { ... } catch (e) { ... }，就足以让整个函数退出优化流水线。
