如何利用 V8 的“内联展开”机制编写对 JIT 编译器友好的高性能纯函数
能被 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)这个内部函数（需要在调试版 DevTools 中开启chrome://flags/#enable-webassembly-simd等实验性功能），再配合--trace-inlining来观察内联过程。
拆分函数时最常踩的坑
把一个 30 行的逻辑函数，机械地拆分成三个 10 行的函数，并不等于性能会自动提升——搞不好，反而会因为增加了间接调用、额外的栈帧开销以及内联缓存失效，拖慢整体性能。
- 拆分策略只应在真正的高频热点路径上考虑，比如
for循环的核心体，或者requestAnimationFrame这类每帧都会执行的回调。 - 拆分出来的每一个子函数，本身仍需满足“纯函数”、“小 AST”、“固定参数个数”这些内联友好条件，否则只是平白增加了调用开销。
- 避免为了传递参数而引入闭包捕获。使用
const local = outerVar然后在子函数中直接访问local，通常比写成sub(x, outerVar)的形式对编译器更友好。 - 如果原来的大函数已经被稳定地内联了，强行拆分后，新的小函数可能因为执行次数不够而达不到“温热”阈值，反而会从优化后的机器码执行，退化到解释执行，得不偿失。
说到底，真正影响 V8 内联决策的，从来不是“你写了几行代码”，而是“你的代码是否让 V8 感到放心”。一个包含了 try/catch 的 3 行函数，和一个没有任何副作用、逻辑清晰的 20 行纯函数，前者在内联的优先级队列里，永远会排在后者后面——因为在 V8 的优化决策链条上，代码的安全性与可预测性，始终压倒一切。
