v8内联函数的核心是控制流可预测性而非代码长度：纯函数（无副作用、无动态绑定、ast平坦）如add、clamp、multiply易被内联；含?.、??、剩余参数、try/catch、eval等破坏可预测性的函数即使很短也会被拒绝；需用--trace-inlining等工具实测验证，且仅对“温热”函数生效。
能被内联的函数，V8 不会把它当“函数”看——它直接把函数体塞进调用点，彻底消除调用开销。但这个决定不是看“你写了多短”，而是看“它敢不敢展开”。
哪些函数大概率被 V8 内联？
内联与否的核心是控制流可预测性，不是行数或字符数。V8 在 TurboFan 阶段必须能静态确认：无副作用、无动态绑定、AST 节点足够平坦。
-
add、clamp、multiply这类三参数以内、仅含比较/算术、无分支嵌套的函数，AST 通常只有 10–20 个节点，极易内联 -
process含?.x或??会触发隐式hasOwnProperty查找，破坏单态 IC，V8 直接放弃内联 -
foo(...args)使用剩余参数会让 AST 引入SpreadElement节点，V8 不信任其结构稳定性，拒绝内联 - 哪怕只有 5 行，只要含
try/catch、eval、this动态绑定或访问arguments，V8 就判定“控制流不可预测”，跳过内联
怎么验证某个函数真被内联了？
别靠经验猜，用 V8 自带诊断开关实测。冷路径（执行少于 10 次）不会触发优化编译，所以测试要保证“温热”。
- Node.js 启动加
--trace-inlining：看到类似[Inlining] add at line 5: inlined into compute才算成功 - 加
--trace-opt可查失败原因，比如not inlineable: contains try/catch或too big for inlining (size=124) - 浏览器环境可用
%OptimizeFunctionOnNextCall(func)（需开启chrome://flags/#enable-webassembly-simd的调试版 DevTools），再配合--trace-inlining观察
拆分函数时最常踩的坑
把一个 30 行逻辑硬拆成三个 10 行函数，不等于性能提升——反而可能因间接调用、额外栈帧、IC 失效拖慢整体。
- 只在高频热点路径（如
for循环体、requestAnimationFrame回调）里考虑拆分 - 每个子函数仍需满足「纯」+「小 AST」+「固定参数个数」，否则只是徒增开销
- 避免为传参引入闭包捕获：用
const local = outerVar+ 直接访问，比sub(x, outerVar)更友好 - 若原函数已稳定内联，强行拆分后新函数未达温热阈值，反而退回到解释执行
真正影响内联的，从来不是“写了几行”，而是“有没有让 V8 放心”。一个含 try/catch 的 3 行函数，和一个无副作用的 20 行函数，前者永远排在后者后面——因为 V8 的优化决策链上，安全性压倒一切。
