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 在类定义完成时就已固定，运行时不可修改；但你可以通过调整继承括号内的类顺序或插入/删除中间类来观察变化。
示例：
立即学习“Python免费学习笔记（深入）”；
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，都会让链在中途断裂。
