动态扩展原型链需权衡性能：应在模块初始化时一次性注入方法以维持引擎优化；避免循环中修改prototype；高频方法应靠近实例层级；推荐工具函数、WeakMap或Proxy替代直接污染原型；instanceof和in操作有隐性开销，可改用constructor.name、hasOwnProperty或Object.create(null)。

动态扩展原型链上的方法确实方便，但会带来可测量的性能代价——关键不在“能不能加”，而在“什么时候加、怎么加、加给谁”。

扩展时机决定性能影响范围

在构造函数实例化前修改 prototype 是最安全的做法。此时所有后续创建的实例都会继承新方法，引擎也能维持隐藏类优化，不会触发去优化（deoptimization）。

• ✅ 推荐：在模块初始化阶段一次性注入，例如 Array.prototype.unique = function() { ... }
• ❌ 避免：在循环中反复给 Constructor.prototype 赋值或删除属性，这会让 V8 放弃对该构造函数的所有内联缓存
• ⚠️ 注意：已有实例不会“丢失”新方法，但它们的原型链引用早已固定；新增方法对它们依然可用，只是无法享受引擎对“稳定原型结构”的优化

扩展方式影响查找效率

直接往 prototype 上挂方法本身开销极小，真正拖慢的是后续高频访问时的查找路径。如果方法定义在深链末端（比如 A → B → C → D.prototype），每次调用都要遍历多层。

• ✅ 建议：将高频使用的方法尽量放在靠近实例的原型层级，避免跨多级继承链调用
• ✅ 可选：对关键方法做实例级缓存，如 this._toString = this.toString.bind(this)，把原型链查找转为直接属性访问
• ❌ 不推荐：用 Object.setPrototypeOf() 动态切换单个对象原型，这会彻底破坏引擎对对象形状的推测，导致所有相关操作退化

替代方案更可控

当扩展需求集中在特定对象或场景时，原型修改不是唯一解。组合优于继承，代理优于污染。

• ✅ 封装工具函数：如 formatDate(obj) 比 obj.formatDate() 更易测试、更少耦合、无原型污染风险
• ✅ 使用 WeakMap 存储私有行为：为每个实例绑定专属逻辑，不干扰原型链，也避免内存泄漏
• ✅ Proxy 拦截访问：需要日志、权限或缓存时，在代理层统一处理，方法仍保留在原型上，但调用可被增强

instanceof 和 in 的隐性成本

看似简单的类型判断和属性检查，底层全是原型链遍历。尤其在数据密集型循环里，它们的开销会随继承深度线性放大。

• ✅ 用构造函数名字符串比对（obj.constructor.name === 'MyClass'）更快，但不防篡改
• ✅ 对已知结构的对象，优先用 hasOwnProperty 或直接访问属性并判 undefined，避免触发整条链查找
• ✅ 若只需键值对操作，考虑 Object.create(null) 创建无原型对象，彻底消除查找开销