手工修复原型链本身不引发性能抖动，真正原因是低效操作：重复创建中转对象、误用属性拷贝、热路径频繁继承；应复用中转函数或用object.setprototypeof，避免拷贝、只链接原型链，constructor修正需一次到位，日常开发优先使用class extends。
手工修复原型链本身不会引起明显性能抖动，真正导致抖动的是修复过程中的低效操作——比如重复创建中转对象、误用属性拷贝、或在热路径中频繁执行继承逻辑。关键不在“修复”动作，而在怎么修、何时修、修什么。
避免每次继承都新建中转函数
常见写法里每次调用继承逻辑都定义 function F() {} 并重设 F.prototype，这会触发 V8 的隐藏类重建和内联缓存失效。应复用静态中转函数，或直接使用 Object.setPrototypeOf（现代环境）替代动态构造：
- 把中转函数声明为模块级常量，不放在继承工具函数内部
- 若目标环境支持，优先用
Object.setPrototypeOf(childProto, parentProto)，它比new F()更轻量且语义清晰 - 避免在循环或渲染帧中反复调用继承封装函数，继承应发生在类定义阶段，而非实例化阶段
不拷贝、不遍历、只链接
寄生组合式继承的核心是原型链链接，不是属性复制。一旦用 Object.assign(Child.prototype, Parent.prototype) 或遍历 for...in 拷贝方法，就破坏了原型链的懒加载特性，还可能覆盖不可枚举方法（如 toString、valueOf），并引发内存与查找开销：
- 子类原型只需正确指向父类原型，所有方法通过原型链自然可查
- 拷贝会把父类原型上所有可枚举属性平铺到子类原型，增大实例的原型对象体积
- 后期父类原型扩展方法时，拷贝过的子类无法自动继承，而原生原型链可以
constructor 属性修复要一次到位
修正 Child.prototype.constructor 是必要步骤，但错误做法是每次设置原型后都执行赋值，尤其在工具函数里重复写 child.prototype.constructor = child。这看似无害，但在某些引擎中可能干扰原型内联缓存（IC）稳定性：
- 确保该赋值仅在原型关系确立后执行一次，且不被后续原型修改覆盖
- 若使用类工厂或动态生成子类，可将 constructor 修正合并进原型设置原子操作中
- ES6 class 编译输出（如 Babel）已对此做了优化，手动实现时需对标其模式：先设原型，再单次修正 constructor
用 class + extends 替代手写寄生组合
现代开发中，99% 场景下无需手写寄生组合式继承。ES6 的 class 和 extends 底层即采用该模式，并经过 V8、SpiderMonkey 等引擎深度优化：
- 引擎对
extends有专用字节码与内联缓存策略，比手写快 10%–30% - 自动处理 constructor 修正、super 调用、原型链完整性，规避人为失误
- 配合
static get [Symbol.hasInstance]()等机制，支持更精准的 instanceof 行为
手写寄生组合继承的价值，主要保留在需要兼容极老环境（如 IE9）、或构建底层框架（如类库的 Class 工具函数）等少数场景。日常业务代码，直接用 class 就是最优解。
