V8优先内联参数少、控制流平、无动态作用域引用的函数；如loadX(o) { return o.x; }这类单属性访问函数极易内联，而含try/catch、闭包捕获或类型不稳定的函数即使很短也会被拒绝。
高频调用的小型纯函数，只要结构干净、无副作用，V8 大概率会内联；但盲目压缩或加 try/catch 会直接让它失效。
哪些函数容易被 V8 内联？
V8 不看行数，看“可推断性”：参数少、控制流平、无动态作用域引用的函数最可能被选中。
-
loadX这类单属性访问函数（return o.x）极大概率内联，尤其在循环中反复调用时 - 只含线性赋值和
if分支、无循环/递归/闭包捕获的函数，即使有 25 行也可能内联 - 使用
const声明参数、始终传入同类型值（如全为number）能提升内联成功率 - 含
eval、arguments、this动态绑定、或try/catch的函数，哪怕只有 3 行，也常被跳过
怎么确认函数是否真的被内联了？
别猜，用 V8 自带的调试标记实测——这是唯一可靠方式。
- 启动 Node.js 时加
--trace-inlining：运行后搜[inlined]或[disabled] reason: too big - 配合
--print-opt-code查看生成的汇编，若调用点已展开为内联逻辑，说明成功 - 注意：仅在函数“温热”（被调用约 10–100 次）后才触发 TurboFan 优化，冷启动阶段看不到内联效果
常见破坏内联的操作有哪些？
这些写法看似无害，实则让 V8 主动放弃内联：
- 在函数体里写
try { ... } catch (e) { ... }—— 即使空 catch 也会阻断 - 访问外层变量（如闭包捕获
largeData），哪怕只读不改，也会降低内联优先级 - 函数参数类型不稳定：先调
add(1, 2)，再调add("a", "b")，不仅导致去优化，还会让后续内联尝试失败 - 用
/* @__PURE__ */注释虽不强制生效，但某些构建工具（如 Rollup）会据此剔除未引用函数，间接影响 V8 的调用热度判断
真正关键的是保持函数“可预测”：它被调多少次、传什么类型、返回什么结构，V8 要能在 Ignition 阶段快速建模。比起删掉换行符，更值得花时间检查闭包捕获范围、统一参数类型、剥离异常处理逻辑到外层。
