17370845950

JavaScript内存管理本质是理解引擎自动分配、追踪与回收机制，核心在于可达性；V8采用标记-清除策略，闭包、未移除事件监听器、全局属性等会阻止回收；WeakMap/WeakRef提供弱引用，FinalizationRegistry用于资源清理；泄漏常因隐式引用导致。

JavaScript 中没有手动内存管理接口，所谓“理解内存管理”，本质是理解引擎如何自动分配、追踪和回收内存，以及你写的代码在什么情况下会意外阻止回收。

垃圾回收器只关心“可达性”

Chrome V8 和其他主流引擎用的是标记-清除（Mark-and-Sweep）策略。它不看变量是否 undefined 或是否被 delete，只看一个对象是否还能从根（global object、call stack 中的局部变量等）通过引用链访问到。

• 闭包中捕获的外部变量，只要内层函数还“活着”，整个外层作用域对象就不可回收
• setTimeout 或 addEventListener 持有的回调函数，如果没被显式移除，会持续持有其词法环境
• 全局对象上的属性（如 window.cacheData = {...}）永远可达，除非手动赋值为 null 或用 delete

WeakMap 和 WeakRef 是真正的“弱引用”

它们不会阻止垃圾回收，适合做缓存或元数据绑定，但使用有严格限制：

• WeakMap 的键必须是对象，且无法遍历；一旦键对象被回收，对应条目自动消失
• WeakRef 需配合 .deref() 使用，返回值可能为 undefined（对象已回收）
• 不能用于 DOM 节点监听（WeakRef 不触发清理回调），此时应优先用 FinalizationRegistry

const registry = new FinalizationRegistry((heldValue) => {
  console.log('对象已被回收，可清理关联资源：', heldValue);
});

registry.register(someElement, 'dom-node-id');

常见内存泄漏模式与检测方式

不是所有“内存增长”都是泄漏——但持续增长且 GC 后不回落，大概率有问题：

• 事件监听器未解绑：element.addEventListener('click', handler) 后忘了 element.removeEventListener
• 定时器未清除：setInterval 返回的 id 没被 clearInterval
• 控制台保留引用：DevTools 中打印过的大对象（如 console.log(largeArray)）会被临时保留，关闭 console 或刷新页面才释放
• 用 Chrome DevTools 的 Memory 面板录制 Allocation Instrumentation on Timeline，能定位哪段代码频繁分配且长期存活的对象

真正难处理的从来不是“怎么释放”，而是“谁还在悄悄引用”。多看 Retainers 树，少信 var a = null 这种表面操作。