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 后不回落，大概率有问题：
立即学习“Java免费学习笔记（深入）”；
- 事件监听器未解绑：
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 这种表面操作。
