javaScript内存管理需主动设计，obj = NULL仅在唯一强引用时有效；WeakMap/WeakSet用弱引用防泄漏；chrome中Detached dom持续增长或Closure长期存活是泄漏信号。
javascript 不需要你手动 malloc 或 free，但**不了解内存管理机制，就等于把性能和稳定性交给运气**。很多“页面越来越卡”“关闭标签后内存不降”“长时间运行后崩溃”的问题，根源都在内存没被正确释放——而垃圾回收器不会替你做设计决策。
什么时候 obj = null 真的有用？
不是所有赋 null 都有意义。它只在“你确定这个引用是唯一阻止对象被回收的强引用”时才起作用。
- ✅ 有效场景：闭包长期存活，且内部持有一个大数组或 DOM 节点，外部已不再需要它 —— 此时
largeData = null能让 GC 下次标记阶段跳过该对象 - ❌ 无效场景：
let obj = {x: 1}; obj = null;——obj本就是局部变量，函数一结束栈帧就销毁，堆上对象自然可达性断开，null是冗余操作 - ⚠️ 注意：对原始值（
String、number）赋null没意义，它们压根不在堆上；只有对象、数组、函数等引用类型才涉及堆内存释放
为什么 WeakMap 和 WeakSet 不会阻止回收？
因为它们的键是「弱引用」——不计入可达性分析。这是少数能真正规避循环引用泄漏的原生方案。
- ✅ 典型用法：给 DOM 元素附加私有状态，又不想阻止元素被移除后回收
const elementMeta = new WeakMap();elementMeta.set(domEl, { loaded: true }); - ❌ 不能用于缓存长期数据：一旦 key（比如某个临时对象）失去其他引用，
WeakMap里对应的 entry 会悄无声息消失，无法预测 - ⚠️ 限制：
WeakMap的 key 只能是对象，不能是string或symbol；且不支持遍历、size属性或clear()
chrome devtools 里哪些迹象说明真出问题了？
别只看“内存占用高”，要看变化趋势和对象留存逻辑。
- ✅ 危险信号：连续拍三次堆快照（Heap Snapshot），筛选
Detached DOM tree—— 如果数量持续增长，说明 DOM 被移除但 js 还拿着引用 - ✅ 危险信号：用 Allocation Instrumentation on Timeline 录制操作，发现某次点击后大量
Closure或Array持续存活超过 10 秒，且没被后续 GC 清掉 - ⚠️ 常见误判：“JS Heap”曲线缓慢上升 ≠ 泄漏 —— V8 会预留空间避免频繁 GC，只要 Full GC 后回落稳定，就属正常；真正要盯的是“每次操作后多留下的那部分”
真正难的不是写 obj = null，而是判断“此刻它是不是那个关键引用”。多数泄漏不是因为忘了清理，而是结构设计时没想清楚谁该持有谁、生命周期是否对齐。比如一个 react 组件卸载了，它的事件监听器、定时器、闭包里的数据，得由谁来负责切断——这已经超出语法范畴，进入系统设计层面。