Python不推荐复杂继承体系，因其降低可读性、引发MRO混乱、增加维护难度，应优先采用组合、协议和依赖注入等更清晰的替代方案。
Python 不推荐复杂继承体系，核心原因是它会让代码变得难以理解、维护和调试，同时违背了“简单优于复杂”的设计哲学。
继承链过长导致可读性急剧下降
当类的继承层级超过三层（比如 A ← B ← C ← D），开发者需要不断向上追溯父类定义才能理解某个方法的来源和行为。方法重写、super() 调用顺序、MRO（方法解析顺序）的隐式影响都会让逻辑变得模糊。
- 阅读子类代码时，无法一眼判断某个属性或方法究竟来自哪一层
- 修改中间某层类，可能意外影响下游多个不相关的子类
- IDE 自动补全和跳转容易失效，尤其涉及动态属性或
__getattr__
MRO 行为在多继承中容易出人意料
Python 使用 C3 线性化算法确定 MRO，但一旦涉及多个父类、钻石继承（如 A ← B, C；D ← B, C），MRO 结果就不再直观。即使写出 D.mro() 查看，也未必能立刻推断出实际调用路径。
- 不同 Python 版本对边缘情况的处理曾有细微差异（虽已稳定，但历史教训仍在）
-
super()在多重继承中依赖准确的 MRO，漏写或错写会导致方法跳过或重复执行 - 混入类（Mixin）若未严格遵循命名和职责约定，极易引发冲突（如两个 Mixin 都定义了
save()）
替代方案更清晰、更可控
大多数原本想靠深继承解决的问题，用组合、协议（Protocol）、依赖注入或简单封装反而更直接。
立即学习“Python免费学习笔记（深入）”；
- 用组合代替继承：把“是什么”（is-a）关系换成“有什么”（has-a），例如用
Logger实例代替继承BaseLogger - 用
typing.Protocol或抽象基类（ABC）声明接口契约，而非强制继承结构 - 用函数式工具（如装饰器、functools.wraps）复用行为，避免为共性功能硬造父类
标准库和主流框架的实际倾向
Python 自身的标准库极少使用深度继承（Exception 层级稍深是特例），collections.abc 中的抽象基类也鼓励“实现协议”而非“继承基类”。Django 和 Flask 等框架的核心组件普遍采用扁平设计 + 显式组合。
- Django 的视图类（
View,TemplateView,ListView）虽有继承，但层级严格控制在两层内，且每层职责明确 - FastAPI 完全放弃基于类的视图继承，回归函数式路由 + 依赖注入
-
dataclass和NamedTuple等工具进一步降低了对继承建模的依赖
不复杂但容易忽略：少一层继承，往往就少一个潜在的 bug 来源和维护盲区。
