原型继承本身不复杂，复杂在于人为滥用；应分层设计：底层保兼容用寄生组合继承，中层日常开发用class语法，顶层靠工具自动降级；优先接口契约与组合，避免冗余继承和状态污染。
原型继承本身不“复杂”，复杂的是人怎么用它——过度抽象、层层代理、手动修补 constructor，反而把简单机制搞成迷宫。真正平衡的关键，不是让原型链更“高级”，而是让它更“可预期”：该深的时候深（如兼容旧环境），该平的时候平（如业务组件），该断的时候断（如用组合替代冗余继承）。
分层设计：底层保兼容，中层写逻辑，顶层靠工具
不要试图用一套原型写法通吃所有场景。现代 JS 项目应按执行环境和职责分层：
- 底层（兼容性锚点）：需支持 IE9–10 或老旧 WebView 时，用寄生组合式继承（空构造函数中转 + 手动修正 constructor），避免 Object.create 直接赋值带来的原型污染风险
-
中层（日常开发）：新业务一律用
class A extends B，由 Babel/TypeScript 编译为高性能 ES5 代码；禁止手动操作__proto__或重写prototype.constructor -
顶层（工程兜底）：用
@babel/preset-env按目标浏览器自动降级，关键基类（如 EventEmitter）提供轻量 polyfill，仅在缺失环境注入
克制继承深度，优先接口契约
原型链每多一层，就多一分隐式依赖和调试成本。与其堆叠 Animal → Mammal → Dog → Poodle，不如用行为契约明确边界：
- 用 TypeScript 的
implements或鸭子类型声明能力（如Drawable、Serializable），而非强制继承某基类 - 共性逻辑抽成独立函数或 mixin（如
withEventEmitting），通过Object.assign混入，但注意只混入方法，不混入可变引用（如数组、对象字面量） - 若必须继承，确保每个层级有清晰的 “is-a” 关系；
AdminUser extends User合理，ReportTable extends Chart就违背语义——它们是不同维度的抽象
用组合替代“伪继承”，尤其对行为型逻辑
很多所谓“需要继承”的场景，本质是需要复用行为，而不是复用身份。原型继承容易模糊这两者：
- 权限控制？让
User持有PermissionService实例，而不是继承AdminMixin - 数据加载？组件接收
request: () => Promise<t></t>函数，而不是继承一个带fetchData()的基类 - 表格行标识？接受
rowKey: string | ((item) => string)，而不是在基类里硬编码id字段逻辑
警惕性能陷阱，不在原型链上做“聪明事”
慢的从来不是原型查找，而是开发者无意中引入的副作用：
- ❌ 避免
Object.assign(Child.prototype, Parent.prototype)—— 这会扁平化方法，切断原型链，失去运行时动态更新能力 - ❌ 禁止在原型上挂
arr = []或cache = {}—— 所有实例共享同一引用，引发状态污染 - ✅ 构造函数内初始化可变状态：
this.items = []；方法定义仍放在原型上，兼顾复用与隔离
不复杂但容易忽略：灵活性不是“能无限扩展”，而是“改一处，只影响该处”。原型继承的优雅，在于它允许你随时切断链、替换行为、注入新能力——前提是别把它当成黑盒，而要清楚每一层在干什么、谁在调用、谁在维护。
