继承仅适用于“is-a”语义关系，如猫是动物、订单是交易；若仅为“has-a”（如汽车有引擎）或单纯复用功能，则应优先选用组合，因其耦合低、易测试、支持运行时替换。
继承确实能复用代码，但不是所有复用都该靠继承实现。关键在于区分“是不是”和“有没有”的关系——只有当子类确实是父类的一种（is-a），才适合用继承；如果只是“拥有某个能力”（has-a），组合或模块化通常更稳、更灵活。
明确 is-a 关系再考虑继承
继承的正当性根植于语义一致性。比如“猫是动物”“订单是交易”这类天然层级关系，父类可封装共性行为（如动物的 eat()、交易的 timestamp），子类专注特化逻辑（猫的 meow()、订单的 pay()）。
- 合理场景：用户系统中 AdminUser、NormalUser 都是 User 的具体类型，共享账号、密码、登录流程
- 反例场景：Logger 不是 Database，即使两者都要写入文件，也不该让 Logger 继承 Database —— 这是功能协作，不是类型归属
- 判断小技巧：把“子类 is a 父类”读出来，如果自然且无歧义，继承才站得住脚
优先用组合替代实现继承
当目标只是复用某段逻辑（比如验证邮箱、压缩数据、发送通知），直接继承一个“工具类”往往带来强耦合和维护风险。组合把能力当作零件装配，更可控。
- 用字段持有依赖对象，而非 extends：ReportService 持有 EmailValidator 实例，而不是继承它
- 接口定义契约，实现类提供能力：IExporter 接口统一 export() 方法，PdfExporter、CsvExporter 各自实现，不共享状态
- 语言特性辅助：Java 的 record + sealed class、Ruby 的 module include、C++ 的 policy-based design，都是比继承更轻量的复用选择
模板与继承结合，兼顾性能与扩展
在底层系统（如推理引擎、图形库）中，纯运行时继承可能拖慢性能，而纯模板又难统一接口。gemma.cpp 的做法值得参考：用模板处理编译期差异（float/bfloat16、不同量化格式），用继承组织高层抽象（Layer、Model）。
- 模板负责“怎么算”：激活函数、矩阵乘法按数据类型特化，零开销
- 继承负责“是什么”：GemmaModel 和 PaligemmaModel 都是 Model 的子类，对外提供一致的 run() 接口
- 二者分层解耦：算法细节由模板隐藏，业务逻辑由继承表达，互不干扰
警惕继承带来的隐性成本
继承不是免费午餐。单继承语言里占掉唯一父类位置，多层继承容易模糊职责，基类改动可能意外破坏子类行为。
- 脆弱基类问题：BaseService 加了缓存逻辑，子类若没重写 update() 就可能漏刷新
- 构造器链复杂：四层继承下，new Child() 要逐级调用父类构造器，初始化顺序难追溯
- 测试负担加重：改父类得回归测所有子类，而组合只需测被组合的对象本身
