闭包开销主要体现在内存占用和属性访问延迟两方面：前者因外部变量被长期持有而增加内存，后者因作用域链查找导致访问变慢；需按需捕获、及时清理、避免滥用。
闭包开销不是指“用了闭包就变慢”，而是指它在内存和访问路径上引入的隐性成本——这些成本在多数场景下可忽略，但在高频、长生命周期或大数据量场景中会显现。关键在于理解“谁被保留”和“谁被访问”。
内存开销：变量不会自动消失
闭包会让被引用的外部变量持续驻留在内存中，即使外部函数早已执行完毕。这不是泄漏，而是设计行为；但若引用了大对象（如 DOM 节点、大型数组、缓存数据），而闭包又长期存在（比如绑定在全局事件、定时器或未销毁的组件实例上），就会推高内存占用。
- 避免在循环中无差别创建闭包并捕获整个作用域，尤其不要在 for 循环里直接给元素绑闭包回调并引用循环变量（易导致所有回调共享同一份变量值，且变量无法释放）
- 只捕获真正需要的值，而不是整个对象。例如用 const id = item.id 提前提取，再传入闭包，而非让闭包直接引用 item
- 当闭包不再需要时，主动解除对外部大对象的引用，例如将内部缓存变量设为 null，帮助垃圾回收器识别可回收区域
属性访问延迟：作用域链查找有代价
每次访问闭包中的自由变量（即外部作用域的变量），JavaScript 引擎都要沿作用域链向上查找。虽然现代引擎做了大量优化（如内联缓存），但相比访问局部变量或对象自有属性，仍多一层间接跳转。
- 频繁读写的闭包变量（如计数器、状态标记）可考虑缓存到局部变量中再操作，减少重复查找
- 避免在 tight loop（如每帧执行数千次的动画逻辑）中反复通过闭包访问深层嵌套的外部属性，例如 config.theme.colors.primary，可提前解构赋值
- 对性能极度敏感的路径，优先使用普通参数传递代替闭包捕获，尤其是基础类型值
最佳实践：按需使用，及时清理
闭包的价值远大于其开销，问题不在“用不用”，而在“怎么用更稳”。真正的风险来自无意识的引用和长期滞留。
- 用闭包封装私有状态时，明确变量生命周期——比如计数器用完即弃，就别让它活在整个应用周期里
- 在事件监听、定时器、Promise 回调等异步场景中使用闭包，务必配套清理机制（removeEventListener、clearTimeout、取消 Promise 订阅）
- 调试时可通过 Chrome DevTools 的 Memory 面板录制堆快照，筛选出疑似由闭包长期持有导致的内存增长对象
