原型链本身不会被清理，关键在于避免实例因原型上的强引用（如共享map）而无法回收；应使用weakmap、实例化初始化状态、及时解绑事件和定时器，并用devtools验证滞留。
原型链本身不会被“清理”，因为原型对象是普通对象，只要还有引用指向它，就不会被垃圾回收。关键不是“清理原型”，而是避免让本该被回收的实例因意外持有原型上的强引用而滞留——这才是实际内存问题的根源。
原型对象不销毁，但实例必须及时断联
原型（如 MyClass.prototype）通常长期存在，它是函数的固有属性，除非显式删除函数或整个模块被卸载，否则不会被 GC。真正需要关注的是：那些本该短命的实例，是否被原型上的共享状态“拖住”了回收时机？
- 禁止在原型上定义可变状态，例如：
MyClass.prototype.cache = new Map()—— 这会让所有实例间接共享一个引用，哪怕某个实例早已不用，只要它的缓存项还在 Map 中，它就无法被回收 - 若需缓存，改用
WeakMap实例化后绑定：const instanceCache = new WeakMap(); instanceCache.set(this, data);—— WeakMap 的键是弱引用，不阻止实例被回收 - 构造函数中初始化实例自身状态，而非依赖原型字段：
this.id = Date.now() + Math.random(); this.items = [];
警惕隐式长引用链
深层原型链（如 A → B → C → Object.prototype）本身不增加内存压力，但会延长属性查找路径，并可能放大闭包或事件监听器带来的引用滞留风险。
- 避免在原型方法中创建闭包并捕获外部大对象（如整个 DOM 节点树、大型数组），尤其当该方法被频繁调用时
- 使用
Object.create(null)创建无内置原型的对象（如配置对象、临时结构体），跳过Object.prototype链，减少隐式引用和属性冲突 - 组件类或工具类中，把高频调用的方法直接挂到实例上（
this.handleClick = () => { ... }），而非依赖原型方法 + 箭头函数绑定，后者容易因this绑定引入意外闭包
销毁阶段主动解绑
实例生命周期结束时，仅设 this = null 没有效果；必须手动切断所有外部强引用。
- 清除事件监听器：
element.removeEventListener('click', this.handler) - 清除定时器：
clearTimeout(this.timerId); this.timerId = null; - 清空对全局缓存（如
window.store或模块级 Map）的注册：cache.delete(this.id) - 若使用 Vue 或 React 组件，确保
beforeUnmount/useEffect cleanup中执行上述操作
验证是否真有滞留
不要凭感觉判断“原型没清理”。用 Chrome DevTools 的 Memory 面板做实证：
- 录制 Allocation instrumentation on timeline，观察高频创建/销毁类的实例是否持续晋升到老生代
- 拍两个堆快照（Snapshot），筛选构造函数名，查看相同类的实例数量是否只增不减
- 选中某个疑似滞留实例，在 Retainers 标签页中逐层查看谁在持有它 —— 常见元凶是原型上的 Map、未清除的事件监听器、闭包中的父作用域变量
