JavaScript继承模型：怎么规避垃圾回收陷阱

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()）

不复杂但容易忽略。真正决定对象能否被回收的，从来不是“有没有继承”，而是“还有没有路径能从根访问到它”。