javascript原型系统是运行时对象行为的底层骨架，本质为对象间委托查找机制，决定代码可维护性、扩展性与性能；es6 class仅为寄生组合继承的语法糖，实际仍操作__proto__与constructor。
JavaScript 原型系统不是语法糖，而是运行时对象行为的底层骨架。从架构师视角看，它决定着代码可维护性、扩展边界和性能底限——不理解原型链，就无法真正掌控类设计、模块复用或框架原理。
原型链的本质：对象查找机制，不是“类继承”
JavaScript 没有传统意义上的类继承，只有对象到对象的委托关系。每个对象内部都有一个隐式 [[Prototype]] 链接（可通过 __proto__ 访问），属性访问时按“自身 → [[Prototype]] → 上级原型 → … → null”逐层查找。
-
构造函数的
prototype属性 是实例对象的__proto__所指向的目标，仅对函数有效；而__proto__是所有对象都有的内部属性（已标准化为Object.getPrototypeOf()） - 数组、日期、正则等内置类型也遵循同一套规则：
[].__proto__ === Array.prototype，Array.prototype.__proto__ === Object.prototype - 修改
Object.prototype会影响几乎所有对象（极危险），但修改Array.prototype只影响数组实例
继承实现的关键权衡：组合 vs 寄生组合
真实项目中，继承不是“能不能”，而是“值不值得”。多数场景应优先用组合（has-a）而非继承（is-a）；若必须继承，需避开经典模式的缺陷。
-
组合继承：父构造函数被调用两次（一次在子类构造内，一次在
Child.prototype = new Parent()中），造成冗余初始化（如重复创建数组、绑定事件） -
寄生组合继承：用
Object.create(Parent.prototype)替代new Parent()，切断父类实例属性对原型的污染，是目前最干净的标准方案 - ES6
class本质仍是寄生组合继承的语法封装，extends底层仍操作__proto__和constructor，并非新机制
原型设计的工程约束：何时该用，何时该绕开
原型链适合共享不可变逻辑（如通用方法），但不适合管理状态或依赖上下文。架构设计中需明确边界：
- 将**纯函数工具方法**挂载到原型（如
String.prototype.trimStart），避免每次新建对象都复制一份 - **避免在原型上存放闭包、this 绑定或异步回调引用**——它们会因共享原型而相互干扰
- 大型应用中，用
WeakMap或 Symbol 实现私有状态，比依赖this+ 原型更可控（例如：存储实例专属缓存或订阅器） - 框架开发中，原型链常用于 mixin 注入（如 Vue 的
methods合并），但需确保合并策略幂等且不破坏原有链
调试与优化：一眼识别原型问题
线上故障常源于原型链断裂或污染。几个快速诊断点：
- 用
Object.getPrototypeOf(obj)和obj.constructor检查链是否符合预期，尤其注意第三方库是否篡改了Array.prototype等原生原型 - 性能敏感路径避免深层原型查找：若某方法被高频调用（如渲染循环中的
getBoundingClientRect），不要把它放在多层原型链末端 - 使用
hasOwnProperty()或Object.prototype.hasOwnProperty.call(obj, key)区分自有属性与继承属性，防止误删或覆盖 - 构建时可通过
webpack的ModuleFederationPlugin或rollup的treeshaking切断未使用的原型方法，减小包体积
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
