super()在多重继承中不按预期调用父类，是因为其依据C3线性化生成的MRO顺序而非继承列表顺序；MRO决定super()调用链中“下一个”类，需确保所有同名方法（尤其__init__）参数兼容并协作调用super()。

为什么 super() 在多重继承里有时不按预期调用父类？

因为 Python 的方法解析顺序（MRO）不是简单按继承列表从左到右线性查找，而是基于 C3 线性化算法生成的拓扑排序结果。当你写 class D(B, C):，D.mro() 返回的序列可能包含 B、C 的共同父类 A，且 A 出现在 B 和 C 之后——这意味着即使 B 定义了 method()，如果它内部用了 super().method()，控制权可能交给 C 或 A，而非直接终止。

常见错误现象：TypeError: method() missing 1 required positional argument，往往是因为某个中间类的 super() 调用跳过了你预期的那个实现，最终落到一个签名不匹配的父类方法上。

• 永远用 D.mro() 查看实际顺序，别靠猜
• super() 在多重继承中不是“上一级”，而是“MRO 中的下一个”
• 所有参与继承链的类，其 __init__ 或其他被 super() 链式调用的方法，参数签名必须兼容（推荐统一用 **kwargs 向下透传）

如何手动验证和调试 MRO 顺序？

直接打印 ClassName.mro() 是最可靠的方式。注意：MRO 在类定义完成时就已固定，运行时不可修改；但你可以通过调整继承括号内的类顺序或插入/删除中间类来观察变化。

示例：

class A: pass
class B(A): pass
class C(A): pass
class D(B, C): pass
print(D.mro())  # [, , , , ]

这里 C 出现在 A 前，是因为 C3 算法要求“B 的祖先不能出现在 C 之后”，而 B 和 C 共享 A，所以 A 必须排在两者之后。

• 如果把 class D(B, C) 改成 class D(C, B)，MRO 中 C 和 B 位置互换，但 A 仍在末尾
• 若某类没继承 object（Python 2 风格），MRO 可能截断，务必确保所有基类最终都继承 object
• 使用 help(ClassName) 也能看到 MRO，但不如 .mro() 直观

什么时候该避免多重继承？

当两个父类各自实现了同名方法，且它们之间没有协作意图（比如都定义了 save()，但逻辑互斥、无法合并），MRO 就成了隐患而非工具。此时 Python 不会报错，但运行时行为取决于谁在 MRO 中更靠前——这容易掩盖设计缺陷。

• 接口类（仅含 pass 方法）+ ABC + 单继承，比多重继承更可控
• 用组合替代继承：把 B 和 C 的能力封装为独立组件，在 D 中以属性持有并显式调用，语义清晰且无 MRO 干扰
• 如果必须多重继承，确保所有同名方法都遵循“协作协议”：每个都调用 super()，且不假设自己是链中最后一个

__init__ 链式初始化为何总出错？

因为 __init__ 是最常被 super() 链式调用的方法，而它的参数最难统一。父类 A 可能期望 name，B 期望 id，C 期望 config——一旦某个环节没把未处理的参数传给 super()，后续类就会因缺少参数而崩溃。

解决方案不是删掉 super()，而是规范参数传递：

• 顶层基类（如 A）的 __init__(self, **kwargs) 最后调用 super().__init__(**kwargs)（即使 object 不需要参数，也

  

  无害）
• 中间类（如 B、C）只提取自己需要的参数，其余原样传给 super()
• 避免在 __init__ 中做重逻辑，优先用工厂函数或 @classmethod 构造实例

MRO 的复杂性在初始化阶段暴露最彻底：它不关心你写了什么，只保证按那个固定顺序逐个调用。漏传、错传、提前 return，都会让链在中途断裂。