JavaScript继承模型：如何避免垃圾回收陷阱？

先说一个基本判断：JavaScript 继承本身并不会直接造成内存泄漏。但继承与原型链、闭包、事件绑定这些机制共同作用时，往往会在不经意间延长对象的生命周期，给垃圾回收机制带来阻碍。继承写法本身不是问题，问题在于“怎么管理引用”。要避免这些陷阱，核心原则有两条：理解什么是可达性，并主动切断那些不再需要的强引用。

闭包引用大对象——继承中的隐形地雷

子类方法如果通过闭包捕获了父类实例中的大型数据——例如一个完整的配置对象、大量 DOM 集合或庞大的缓存数组——即使子类方法只用到其中的一两个字段，整个父类实例也可能因此无法被回收。需要特别警惕以下几点：

• 避免让构造函数中返回的实例方法，通过闭包隐式捕获整个父作用域里的大对象。
• 如果子类确实需要复用父类的某个字段，应当显式提取这个值，而不是直接捕获整个 this 或 parentRef。
• 推荐使用 Object.assign({}, parent.data) 或通过解构 { id, name } = parent 来取值，这比直接持有 parent 引用更安全。

原型链上挂监听器或定时器——共享带来的风险

直接把事件监听器、setInterval 的回调定义在原型上，看似能节省内存。但风险恰恰出在“共享”上：一旦某个实例绑定后没有清理，回调里的 this 会持续引用这个实例，而原型方法又被所有实例共享。结果是一个实例泄漏可能拖累一串实例都无法释放。

• 尽量避免在原型方法里直接注册全局或长生命周期目标的监听器（例如 window.addEventListener）。
• 如果非注册不可，必须在实例销毁时干净地调用 removeEventListener，且监听器函数必须是实名函数，不能用匿名函数，否则无法精确移除。
• 定时器的 ID 应保存在实例属性上，在 destroy 或 unmount 方法中通过 clearInterval(this.timerId) 清理干净。

子类握着父类引用不放——一个容易被忽略的场景

这在组合式继承或寄生组合式继承中特别常见：子类构造函数执行完 Parent.call(this, ...) 之后，顺手把整个 Parent 实例挂到了 this.parentRef 上，后面再也用不上却一直没释放。这种情况在性能监控中非常显眼。

• 先问自己：真的需要在实例的整个生命周期里长期持有父类引用吗？大多数场景只是初始化时读一次就够了。
• 如果只是临时关联某个关系，可以用 WeakMap 来存储父子引用，弱引用不会阻碍垃圾回收。
• 提供一个显式的 cleanup() 方法，在业务逻辑结束时毫不犹豫地执行 this.parentRef = null。

静态属性与单例继承链——这也是最容易漏掉的

通过 class.extend() 或静态工厂创建的“继承型单例”，很容易因为静态属性（例如 MySubClass.cache = new Map()）长期持有 DOM 节点、回调函数或大型数据而引发泄漏。这往往是排查时的盲区。

• 静态缓存结构优先选用 WeakMap 或 WeakSet，尤其当 key 是 DOM 元素或组件实例时。
• 给静态 Map 设置容量上限，配合 LRU 淘汰策略，避免无限增长。
• 在模块卸载或测试 teardown 阶段，主动清空静态引用，例如 MyClass.cache.clear()。

说到底，这些东西并不复杂，但确实容易被忽略。真正决定一个对象能否被回收的，不是“有没有用继承”，而是“还有没有路径能从根访问到它”。记住这一点，很多问题便会迎刃而解。