前端组件化继承应控制在两层内（basecomponent→featurecomponent），优先用组合、hook或策略模式替代深层继承，父类接口需显式声明并校验，每次继承须配套文档与测试。
前端组件化开发中，合理的继承树不是“越多层越高级”，而是以可读、可测、可替换为前提，控制层级、明确职责、留出扩展余地。ES6 class + extends 是唯一推荐语法入口，但真正决定质量的是设计约束，不是语法本身。
继承深度严格限制在两层以内
只允许 BaseComponent → FeatureComponent 这样的单级继承。禁止出现 A → B → C 或更深的链式结构。超过一层时，必须走评审流程，并优先考虑替代方案：
- 把中间层逻辑拆成独立 hook 或工具类（如 useFormState、withErrorBoundary）
- 用组合方式注入能力：子组件持有一个配置对象或服务实例，而不是继承它
- 对行为分支多的场景，改用策略模式 + 工厂函数，避免靠继承分支控制流程
父类只暴露受保护契约，不开放隐式访问
BaseComponent 不是“万能容器”，所有供子类覆盖或调用的接口必须显式声明：
- 生命周期方法统一用 on 开头命名（如 onMount、onUpdate、onUnmount），并在 JSDoc 中标注 @protected
- 父类内部调用子类方法前，必须先检查 typeof this.onBeforeRender === 'function'
- 禁止子类直接读写父类私有字段（如 this._cache、this.__state），状态交互全部走 public 方法或 getter/setter
每个继承关系必须配套文档与测试
上线前必须同步交付两项资产，缺一不可：
- 一份 inheritance-map.md：用文字或树状图说明谁继承谁、为什么继承、哪些方法被重写、哪些 super 调用不可省略
- 一个单元测试文件（如 ButtonGroup.test.js）：覆盖父类方法是否可调、重写方法是否生效、super 是否被正确执行、异常下是否安全降级
优先用组合替代继承来复用逻辑
当多个组件需要共享某类能力（如表单校验、加载状态、权限拦截），不要新建一个 FormBase → AuthBase → LoadingBase 的继承链，而应：
- 将能力封装为可插拔的 mixin 或 Composition API（Vue） / Hook（React）
- 让组件通过 props 或 context 接入，而非强制继承
- 对第三方 SDK 或底层渲染器，用组合方式持有实例（如 class Chart { constructor(renderer) { this.renderer = renderer; } }）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
