闭包本身不是性能瓶颈，但会阻碍JIT内联优化，因其捕获的自由变量具有运行时可变性，破坏了编译器所需的确定性；变量逃逸、类型不稳定或跨上下文引用进一步导致内联失效。
闭包本身不是性能瓶颈，但它的存在方式会直接影响 JIT 编译器是否能对函数做内联优化。现代引擎（如 V8）在函数被高频调用后，会尝试把被调用函数的代码“贴”进调用处，省去函数调用开销。而一旦函数形成闭包并被外部持有，这个优化通常就被关掉了。
为什么闭包会让内联失效
内联的前提是“确定性”：编译器必须能确认该函数的行为不会因外部变量变化而意外改变。但闭包捕获的自由变量可能在运行时被任意修改——比如从外部改了外层的 let 变量，或通过引用修改了对象属性。这种不确定性让引擎不敢内联，怕生成错误代码。
- 函数返回后仍被赋值给全局变量、传入事件监听器或 Promise 回调，就构成“逃逸”，基本触发不可内联标记
- 即使函数逻辑极简单（比如只读一个变量），只要它被闭包捕获并暴露出去，V8 就大概率跳过内联
- 可通过 Chrome DevTools 的 Optimization tab 查看函数状态，或用 %GetOptimizationStatus(fn) 验证是否被标记为 “Inlined”
哪些写法更利于保持内联机会
关键不是避免闭包，而是控制闭包的“可见范围”和“变量稳定性”。
- 把需要内联的函数限制在局部作用域内使用，比如立即调用或仅作为参数传给可信的同步函数
- 避免让闭包持有可变的大对象；若只需某个字段，提前解构或缓存为局部常量（const value = obj.field）
- 用 let/const 声明被捕获变量，比 var 更易被引擎跟踪生命周期；循环中优先用 for (let i...) 而非 var
- 保持被捕获变量的类型稳定，比如始终是 number 或 string，避免 null / undefined / object 混用
闭包与内联不是对立关系，而是协作边界问题
引擎并不排斥闭包，它排斥的是“不可预测的变量访问”。如果你的闭包只读取参数或 const 常量，且不暴露到异步上下文，V8 仍可能内联它。真正的阻碍来自自由变量的可变性、作用域逃逸和跨执行上下文引用。优化方向不是消灭闭包，而是让闭包更“透明”、更“可控”。
