继承本身不是问题，真正要防的是用继承掩盖设计缺失；应警惕虚假“is-a”关系，优先用接口或协议定义行为，单层继承够用时勿叠加，多层继承易导致职责模糊、修改风险高、测试成本陡增。
继承本身不是问题，问题在于把“能复用”当成“该继承”。层次过深的继承链，往往意味着职责模糊、修改牵一发而动全身、测试成本陡增。真正要防的，不是继承本身，而是用继承去掩盖设计缺失。
警惕“is-a”关系的虚假成立
很多深继承是从一个看似合理的分类开始的：比如Animal → Mammal → Canine → Dog → Labrador。逻辑上成立，但业务中几乎无用——90%的代码并不关心“拉布拉多是不是犬科”，只关心“它能不能吠叫”或“它有没有疫苗记录”。一旦需求变动（比如要支持“电子宠物”），整条链就得重构。
- 问自己：这个子类是否必须替换父类出现在所有上下文中？如果不是，就不是真正的“is-a”
- 优先用接口（ABC）或协议（Protocol）定义行为契约，而不是靠继承强制类型归属
- 如果只是为了共享几个方法，混入类（Mixin）或组合更轻量、更可控
单层继承够用时，别叠第二层
Python项目中，80%以上的可维护继承结构是单层的：子类直接继承一个抽象基类或稳定的具体基类。多层继承（A→B→C→D）通常只在框架内部封装中出现（如Django的Model → BaseModel → Deferrable → object），普通业务代码极少需要。
- 每增加一层，就多一层MRO依赖、多一层初始化责任、多一层文档和测试覆盖压力
- 若发现子类主要在重写父类方法而非扩展新能力，说明父类已承担过多职责，该拆分而非加深
- 用
print(YourClass.__mro__)定期检查——如果MRO长度超过4，就要停下来评估必要性
用组合替代“为了复用而继承”
当想通过继承获取某功能（比如日志、缓存、序列化），大概率走错了路。这些是横切关注点，不属于领域本质，不该靠继承绑定到模型上。
- 把功能封装成独立组件：
LoggerService、CacheManager，在需要的类里作为属性持有 - 避免
class Order(LoggingMixin, CachingMixin, ValidationMixin)这类混入堆砌——职责不清，调试困难 - 组合带来显式依赖：谁用了什么、何时调用、如何配置，一目了然；继承则隐式传递，容易漏掉关键初始化步骤
重构深继承的实用信号
以下迹象说明继承层次已经失控，该动手简化：
- 子类中大量出现
super().xxx()调用，且不确定调的是哪一层的实现 - 修改父类某个方法，导致下游多个子类行为意外变更，却找不到明确文档说明影响范围
- 单元测试里不得不mock 3层以上的父类方法才能隔离测试当前类
- 新人接手时第一句话是：“这个类到底从哪儿继承来的？我得先画张图”
