v8内联展开的核心是安全性而非函数大小或调用频次：纯函数（无副作用、无动态绑定、无eval/try-catch）、结构平坦、参数固定且类型稳定，才满足内联前提；需用--trace-inlining等工具实测验证。

要让 V8 的内联展开机制真正起效，核心不是“写小函数”，而是写“V8 能放心展开”的函数——它看重的是确定性、可预测性与结构简洁性，而非行数或调用次数。

纯函数是内联的前提，不是修饰词

所谓“纯”，在 V8 眼里有明确定义：无副作用、不访问动态绑定（如 this、arguments）、不触发隐式查找（如可选链 ?. 、in 操作符）、不含 eval、try/catch、with 等破坏控制流的语法。哪怕只有 4 行，只要出现 try { return x; } catch {}，V8 就会直接标记为 not inlineable。

• ✅ 推荐：function add(a, b) { return a + b; } —— AST 平坦、无分支、无隐藏语义
• ❌ 避免：function safeAdd(a, b) { try { return a + b; } catch { return 0; } } —— 控制流不可静态推导
• ⚠️ 注意：function getVal(obj) { return obj?.x; } 触发 hasOwnProperty 查找，破坏单态 IC，基本不会内联

参数和返回值必须“干净”且稳定

V8 对接口形态非常敏感。参数个数固定、类型倾向一致（尤其在热点路径中反复传 number/string）、返回值无歧义，才能触发类型特化和逃逸分析，进而打开内联通道。

• ✅ 推荐：function clamp(min, val, max) { return val max ? max : val; } —— 三参数、全比较、单返回、无对象操作
• ❌ 避免：function sum(...nums) { return nums.reduce((a, b) => a + b, 0); } —— 剩余参数导致 AST 复杂，nums 是类数组对象，V8 不信任其结构
• ⚠️ 注意：function process(input) { return input.id ?? input.key; } —— 空值合并引入属性存在性判断，类型反馈易退化为多态

别为了拆分而拆分，警惕“伪优化”陷阱

把一个逻辑清晰的 25 行函数硬拆成三个 8 行函数，常导致性能下降。V8 的内联决策基于整体收益：间接调用开销、栈帧增长、IC 失效、闭包捕获增加，都可能抵消“变小”带来的好处。

• 只在以下情况拆分才真正有益：子函数本身高频出现在热点路径（如循环体、raf 回调），且每个子函数仍满足「纯 + 小 AST + 固定参数」
• 避免通过参数传递外层变量来“解耦”，比如把 const config = { scale: 2 }; 作为参数传入子函数——这比直接访问局部 const 更易破坏内联，因参数类型可能不稳定
• 若原函数含少量条件分支但整体结构简单（如带 guard clause 的计算），保留为单函数反而更易被内联；强行拆出会引入额外调用点，得不偿失

用工具验证，而不是凭感觉猜测

是否内联不能靠经验判断，必须实测。Node.js 下启用诊断开关是最可靠方式：

• 运行命令：node --trace-inlining script.js，观察输出中是否有 [Inlining] funcName at line X: inlined into caller
• 加 --trace-opt 可看到拒绝原因，例如 not inlineable: contains eval 或 too big for inlining (size=92)
• 注意：V8 只对“温热”函数（执行约 10–100 次）触发 TurboFan 优化编译，冷路径不会内联，测试时需确保函数被充分调用
• 浏览器环境可用 %OptimizeFunctionOnNextCall(func)（需开启 chrome://flags/#enable-webassembly-simd 的调试版 DevTools）强制触发，再配合 --trace-inlining 观察