v8内联函数的关键是安全性而非调用频次或代码长度：纯函数（无副作用、无闭包捕获、无动态绑定）、ast简单、类型稳定、控制流可预测的函数才易被内联；含try/catch、eval、可选链、剩余参数等破坏可预测性的结构，即使仅3行也会被拒绝。
能被内联的函数，V8 不会把它当“函数”看——而是直接把函数体代码复制进调用点。所以关键不是“怎么写得短”，而是“怎么写得让 V8 敢放心展开”。
什么样的函数会被 V8 内联？
V8 内联决策基于安全性，而非调用次数或行数。只要函数结构破坏了控制流可预测性，哪怕只有 3 行，也会被拒之门外。
-
add被内联，是因为它无副作用、无闭包捕获、无this或arguments、AST 简单（纯二元运算） -
computeWithSideEffect不被内联，哪怕只含一个try/catch或eval，V8 就放弃逃逸分析和类型特化 - 访问
obj?.x或obj['x']会触发隐式hasOwnProperty查找，破坏单态 IC，连带影响内联意愿 - 使用剩余参数
function foo(...args)让 AST 复杂化，args是 Array-like 对象，V8 不信任其结构稳定性
哪些参数与返回模式最利于触发内联？
内联成功率高度依赖类型稳定性和接口简洁性。V8 希望看到“可预测的输入 → 可预测的输出”链条。
-
clamp(min, value, max)：三参数、单返回、全比较分支，结构平坦，大概率内联 -
multiply(a, b)：若在循环中反复传number，配合隐藏类稳定，内联概率高 -
process(obj)：哪怕只有一行obj?.x ?? 0，因可选链引入动态查找，大概率不内联 - 避免
function foo(args) { return args[0] + args[1]; }：剩余参数 + 方括号访问 = 双重 IC 破坏点
怎么确认你的函数真的被内联了？
别靠经验或猜测。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 次），冷路径不会触发 TurboFan 优化编译
- 浏览器环境可用
%OptimizeFunctionOnNextCall(func)（仅限开启chrome://flags/#enable-webassembly-simd的调试版 DevTools）强制触发，再配--trace-inlining观察
拆分函数时最容易踩的性能坑
把一个 30 行逻辑硬拆成三个 10 行函数，不一定更快——反而可能因间接调用、额外栈帧、IC 失效拖慢整体。
- 是否高频出现在热点路径（如
for循环体、requestAnimationFrame回调）是首要判断依据 - 拆分后每个子函数仍需满足「纯」+「小 AST」+「固定参数个数」，否则只是徒增开销
- 引入闭包捕获（比如把外层
const config通过参数传入）比直接访问局部常量更重，V8 需要维护上下文引用 - 函数间传递对象时若属性访问不一致（如 A 函数读
.x，B 函数读.y），V8 为每个函数维护独立 IC 表，无法复用
真正影响内联的，从来不是代码长度，而是你有没有无意中写出了 V8 无法做静态推断的结构——比如一个 try、一个 ??、一次 Object.keys()，都可能让整条热路径掉出优化轨道。
