V8内联小函数可显著提升高频纯函数性能，关键在于满足纯度、结构可预测性等条件，并通过--trace-inlining等工具实测验证。

直接让 V8 把小函数的逻辑“塞进”调用处，省掉函数调用开销、激活后续优化（比如类型特化、逃逸分析），这是提升高频纯函数性能最有效的手段之一。关键不是写得多短，而是让 V8 “愿意且能安全地内联”。

确认函数是否已被内联

别靠猜测，用 V8 自带开关实测：

• Node.js 启动时加 --trace-inlining，运行后搜索控制台输出中的 [inlined] 或 [disabled] reason: too big 等标记
• 加 --trace-opt 可看到更细粒度原因，例如 not inlineable: contains try/catch 或 too big for inlining (size=124)
• 浏览器环境可用 %OptimizeFunctionOnNextCall(func)（需开启 chrome://flags/#enable-webassembly-simd 的调试版 DevTools）强制触发一次优化编译，再配合 --trace-inlining 观察

提升内联成功率的核心条件

V8 判断是否内联，看的是结构可预测性，不是行数本身：

• 函数必须是纯的：无副作用、不读写全局/外部变量、不依赖 this 或 arguments
• 避免破坏性结构：try/catch、with、eval、arguments 访问、动态作用域引用（如访问上层未声明为 const 的变量）
• 参数个数固定、类型倾向稳定（例如始终传 number），有助于 TurboFan 做类型特化假设
• 函数体控制流尽量平坦：少嵌套、少递归、少复杂循环；线性赋值 + 明确 if/else 比 15 行但含 3 层 for 更易被内联

拆分与合并的实用边界

不是越小越好，也不是越大越差，要结合执行路径判断：

• 只对“温热”函数生效（通常执行 10–100 次后），冷路径不会触发优化编译
• 高频出现在热点路径（如 for 循环体、requestAnimationFrame 回调）的小函数，才是内联收益最大的目标
• 硬拆一个 30 行逻辑为三个 10 行函数，可能因间接调用、额外栈帧、IC 失效反而变慢
• 若子函数引入闭包捕获（比如把外层变量当参数传入），比直接访问 const 局部变量更难内联

验证与微调建议

优化必须基于观测，而非直觉：

• 用 --print-opt-code 查看生成的汇编，确认调用点是否已展开为内联逻辑
• 对关键小函数未被内联的情况，优先尝试提取纯计算片段、简化控制流、移除异常处理，而不是盲目压缩成一行
• /* @__PURE__ */ 注释虽不强制内联，但部分构建工具会传递该提示，辅助 V8 推断纯度
• 避免为“代码整洁”而过度拆分——把本该内联的热函数变成多次 call，等于主动放弃优化机会