Object.setPrototypeOf() 和直接修改 proto 在GC层面开销无本质差异，二者均不直接增加GC压力，但会间接影响旧原型的可达性与回收时机；真正决定回收的是引用关系是否断开及引擎能否准确判定不可达。
直接修改 __proto__ 和调用 Object.setPrototypeOf() 在垃圾回收（GC）层面的开销差异，本质上不是“谁更费 GC”，而是**两者都不直接增加 GC 压力，但会间接影响原型对象的可达性与回收时机**。真正决定 GC 开销的是：旧原型是否还被其他对象引用、是否形成循环引用、以及引擎能否及时识别其不可达。
旧原型何时会被回收？
无论用哪种方式改原型，只要旧原型不再被任何活跃对象引用（包括新原型链、闭包、全局变量、WeakMap键等），它就符合回收条件：
- 通过
Object.setPrototypeOf(obj, newProto)修改后，若原原型oldProto没有被其他对象持有，且没被闭包捕获，V8 会在下一次 GC 周期将其标记为可回收 - 直接赋值
obj.__proto__ = newProto效果相同——只是操作方式非标准，但对原型对象本身的引用关系变更逻辑一致 - 关键区别不在 GC，而在**引擎是否能准确、及时地推断出旧原型已不可达**。使用
Object.setPrototypeOf()时，引擎明确知道这是受控的原型变更，可配合隐藏类状态做更可靠的可达性分析；而__proto__赋值因非标准化，某些引擎可能延迟或误判引用关系
为什么说 GC 开销不是主要问题？
原型对象本身通常很小（只是普通 JS 对象），即使暂时未回收，内存占用也有限。真正带来性能代价的环节在运行时，而非 GC 阶段：
-
__proto__赋值会绕过引擎的原型变更监控机制，可能导致内联缓存失效更隐蔽、去优化更难诊断 -
Object.setPrototypeOf()虽然也会触发去优化，但它让引擎能统一处理原型重连逻辑，旧原型的引用状态更可预测，反而利于后续 GC 判定 - 如果旧原型是某个大型对象树的根（比如一个共享的工具原型），且被多个对象复用，那么改原型并不会立刻释放它——只要还有一个对象指向它，它就存活。这和用哪种 API 修改无关，只取决于引用图
实际影响 GC 的常见陷阱
真正拖慢 GC 或导致内存滞留的，往往不是改原型这个动作本身，而是伴随的设计模式：
- 用
Object.setPrototypeOf()动态给大量对象设置同一原型，又未清理引用，造成该原型长期驻留堆中 - 在
__proto__赋值后意外保留了对旧原型的闭包引用（例如在 setter 中缓存了 oldProto），人为制造强引用 - 将原型对象作为 WeakMap 的键，但 WeakMap 实例本身被长期持有——此时原型不会被回收，无论是否改过
[[Prototype]]
怎么判断原型是否已被回收？
没有直接 API 查看某个对象是否已被 GC，但可通过间接方式观察：
- 在 Chrome DevTools 的 Memory 面板录制 Heap Snapshot，筛选构造函数名或属性特征，确认旧原型实例是否仍存在
- 配合
console.memory观察 JS 堆内存趋势，若频繁调用 setPrototypeOf 后内存持续增长且不回落，需检查原型引用泄漏 - V8 提供
%DebugPrint(obj)（需启用--allow-natives-syntax）可查看对象是否处于字典模式、是否有活跃隐藏类——这比盯 GC 更反映真实运行态
