原型链查找本身不增加内存占用，但与闭包共存时可能间接加剧内存泄漏——闭包决定变量是否被保留，原型链可能延长其生命周期。
原型链查找逻辑本身不直接影响闭包的内存占用，但二者在实际编码中常共存，间接加剧内存压力——关键在于变量引用是否被意外延长、作用域链是否被冗余保留。
原型链查找不会触发闭包变量捕获
原型链只是属性访问时的向上查找机制（从实例→__proto__→原型→Object.prototype），它不执行函数、不创建执行上下文，也不捕获任何外部变量。闭包的形成只取决于函数定义时词法作用域中变量是否被内层函数引用，和原型链无关。
例如：
function createCounter() {
let count = 0;
return function() {
count++; // 闭包：捕获了 count
return count;
};
}
const inc = createCounter();
inc(); // 1
// 即使给 inc 添加原型方法，也不会让 count 多留一秒
inc.__proto__.log = function() { console.log('hi'); };
但原型链可能“掩盖”闭包导致的内存滞留
当闭包持有大对象（如 DOM 节点、大型数组），而该闭包又被挂载到某个长期存活的对象原型上，就容易让人误以为是原型设计问题，实则根源在闭包未释放。
立即学习“Java免费学习笔记（深入）”；
- 闭包函数被赋值给构造函数的 prototype 属性，会导致所有实例共享该函数——若该函数内部引用了外层大对象，所有实例都会间接持有所引用对象
- 用 Object.setPrototypeOf() 动态修改对象原型，并把含闭包的函数塞进新原型，也会延长闭包生命周期
- 常见陷阱：在事件监听器中返回闭包函数，又将该函数绑定到原型方法上，结果监听器无法移除 → 闭包+DOM+原型三者环状引用
优化建议：切断不必要的引用链
闭包内存问题本质是“不该活的变量活得久”，原型链不是元凶，却是放大器。重点控制变量生命周期：
- 避免在闭包中直接引用 DOM 元素或大型数据结构；改用 ID、索引等轻量标识，需要时再查
- 不用 prototype 存储依赖外层变量的函数；这类函数应定义在实例上，或确保外层变量可被及时回收
- 手动清理：在不再需要闭包时，将引用设为 null（尤其对定时器、事件监听器）
- 用 WeakMap 存储与对象关联的私有数据，避免强引用阻止 GC
一句话总结
原型链负责“找得到”，闭包决定“放不下”；前者不增加内存，后者若设计不当，再经原型链传播，就容易变成隐蔽的内存泄漏源。
