多继承应慎用，优先以super()和mro自动调度；适用场景为正交mixin组合与接口兼容+行为复用；需约束mro、避免同名方法冲突、用abc替代部分需求，并通过测试验证初始化与销毁行为。
Python多继承本身不难，难的是怎么用得清楚、改得安心。核心原则是：能不用就不用；非用不可时，优先靠super()和MRO自动调度，而不是手动调父类方法。
明确“为什么需要多继承”
多继承不是炫技工具，它适合解决两类问题：
-
组合式能力扩展：比如一个类既要可序列化（
SerializableMixin），又要支持缓存（CacheableMixin），还要带日志（LoggableMixin）——这些职责正交、无状态、不互相依赖，用Mixin类叠加最自然； -
接口兼容+行为复用并存：例如同时实现
__len__和__iter__（来自不同抽象基类），又需要复用某框架的通用实现逻辑。
如果只是为了“少写几行代码”而拉进多个父类，或者父类之间存在隐含状态耦合（比如都操作同一个实例属性self._config），那大概率是设计信号异常，应转向组合或协议（Protocol）替代。
严格约束MRO结构，拒绝“菱形陷阱”的变体
Python用C3线性化算法确定MRO，但人脑很难直觉推演深层嵌套下的调用顺序。因此要主动控制：
立即学习“Python免费学习笔记（深入）”；
-
所有Mixin类必须继承自
object，且不重写__init__（或只做super().__init__()转发）； -
避免在多个父类中定义同名方法（尤其是
__init__、__call__、save等关键行为）； -
用
ClassName.__mro__或help(YourClass)随时验证继承链，重点关注你关心的方法落在哪一层； - 若必须覆盖同名方法，统一用
super().method_name()链式调用，不要硬编码父类名（如ParentA.method()），否则破坏MRO语义。
用抽象基类（ABC）替代部分多继承场景
很多所谓“多继承需求”，其实只是想表达“我支持X协议 + Y协议”。这时ABC更轻量、意图更清晰：
- 定义
class Readable(ABC): @abstractmethod def read(self): ...； - 定义
class Writable(ABC): @abstractmethod def write(self): ...； - 具体类只需
class FileHandler(Readable, Writable): ...，不引入实现细节，只声明契约； - 配合
isinstance(obj, Readable)做运行时检查，比靠继承关系判断更可靠。
ABC不提供实现，也就规避了方法冲突和初始化顺序问题，适合定义能力边界。
测试驱动多继承行为，尤其关注初始化与销毁
多继承下__init__和__del__最容易出错。建议：
- 每个Mixin类的
__init__只接收自己关心的参数，并全部转发**kwargs给super()； - 编写单元测试，显式检查MRO顺序：
assert YourClass.__mro__[1:] == (MixinA, MixinB, object)； - 对涉及资源管理（如打开文件、启动线程）的Mixin，单独测
__init__是否被调用、__del__或close()是否被正确触发； - 用
pytest -s加打印，观察实际调用路径，比纯推理更可信。
不复杂但容易忽略。
