原型链本身不会直接导致内存泄漏，但不当使用原型、构造函数与实例间的引用关系，尤其混入闭包、事件监听或全局缓存时，易形成隐式循环引用，干扰垃圾回收。
原型链本身不会直接导致内存泄漏，但不当使用原型、构造函数与实例间的引用关系，尤其混入闭包、事件监听或全局缓存时，容易形成隐式循环引用，干扰垃圾回收（特别是标记清除机制），最终表现为内存持续增长。要定位这类问题，关键不是“看原型链”，而是通过堆快照识别被意外强引用的实例或闭包，再逆向追踪其 retaining path 中是否包含原型链上的冗余持有。
拍快照前必须手动触发 GC
Chrome Memory 面板中，点击“Collect garbage”（小垃圾箱图标）后再拍堆快照，否则快照里堆满本该回收却滞留的对象，干扰判断。原型相关泄漏常藏在闭包或 DOM 引用中，若不先清理，它们会掩盖真实泄漏点。
重点筛选 Retained Size 大的 (closure) 和构造函数实例
在 Heap Snapshot 的 Summary 视图中，按 Retained Size 降序排列，重点关注：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 以 (closure) 开头的条目：说明某个函数闭包长期存活，很可能捕获了本该释放的实例或 DOM 节点；
- 你自定义的构造函数名（如 Person、Modal）：若数量随操作反复增加且不回落，说明实例未被回收；
- HTMLDivElement 或其他 DOM 类型后带 Detached 前缀：表明元素已从 DOM 移除，但仍被 JS 持有——而持有者常常是闭包中通过原型方法访问的 this 或缓存对象。
顺着 Retaining Tree 查闭包的引用源头
右键某可疑 closure 或实例 → “Reveal in Summary view” → 切换到 “Retainers” 标签页，展开 retaining path。此时注意以下几类路径节点：
- closure → [[Scopes]] → Closure → Variable: instance：说明闭包显式捕获了实例；
-
closure → [[Scopes]] → Closure → Variable: this：常见于事件回调中绑定的原型方法（如
el.addEventListener('click', this.handleClick)），若组件销毁未解绑，this 就锁住整个实例及其原型链； -
global → window.cache → Array → Object → instance：全局缓存对象意外持有实例，而该实例的
__proto__又指向原型，原型上若存有对其他大对象的引用（比如缓存的 DOM 或数据），就会形成跨层级强引用链。
原型链本身不是泄漏源，但会放大引用影响
原型对象（Constructor.prototype）本身是共享的，通常不会造成泄漏。真正危险的是：实例通过原型方法间接维持对外部对象的强引用。例如：
function ListManager() {
this.items = [];
}
ListManager.prototype.renderItem = function(item) {
// 闭包捕获了外部作用域的 this（即实例），而 this.items 可能引用大量 DOM
return () => {
document.body.appendChild(item.el); // item.el 是 detached DOM，但被 this.items 持有
};
};
此时 renderItem 返回的箭头函数形成闭包，持有了 this（ListManager 实例），而 this.items 又持有已 detach 的 DOM 节点。原型方法只是“通道”，泄漏根源在于闭包 + 实例属性 + 未清理 DOM 的组合。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
