super() 在多重继承中按 MRO（Method Resolution Order）顺序查找方法，遵循 C3 算法生成的线性序列，所有参与类必须统一使用 super() 保证调用链连续，混用显式类名调用会破坏 MRO。
super() 在多重继承中到底按什么顺序找方法？
Python 的 super() 不是简单地调用父类，而是依据 MRO（Method Resolution Order）列表从当前类的下一个位置开始查找。你可以用 ClassName.__mro__ 或 ClassName.mro() 查看实际顺序。比如 class C(A, B): pass 的 MRO 是 (C, A, B, object)，不是按代码书写顺序“先 A 后 B”就完事——它受所有参与类的 MRO 共同约束，最终形成一个线性、一致、满足 C3 算法的序列。
常见错误现象：明明写了 super().__init__()，但某个父类的 __init__ 根本没执行，或者被重复执行两次。这往往是因为部分类没写 super()，或某处用了硬编码的类名调用（如 A.__init__(self)），破坏了 MRO 链的连续性。
- 所有参与多重继承的类，只要希望被链式调用，其方法（尤其是
__init__）都必须使用super()，不能跳过 - 如果某个类不打算参与协作初始化，就别把它放进继承列表里；否则它会卡住 MRO 链
- 避免在同一个继承体系中混用
super()和显式类名调用，这是最典型的断裂点
为什么 __init__ 参数不一致会导致 super() 调用崩溃？
当多个父类的 __init__ 接收不同参数时，super().__init__(...) 传参稍有不慎就会报 TypeError: __init__() takes X positional arguments but Y were given。这不是 super() 的 bug，而是参数签名在 MRO 链上传递时错位了。
典型场景：你定义了 class A: 接收 name，class B: 接收 age，而 class C(A, B): 想同时传 name 和 age。但 A.__init__ 并不认识 age，B.__init__ 也不认识 name。
立即学习“Python免费学习笔记（深入）”；
- 统一用
**kwargs接收并透传，让每个类只取自己需要的键，其余继续交给super() - 不要在中间类里做参数校验或提前
pop，除非你确保后续类不再需要它 - 如果必须强类型校验，放到最顶层的构造逻辑里（比如工厂函数或单独的验证方法），而非分散在各
__init__
如何验证 super() 是否真的走完了整个 MRO 链？
光看代码写得“对称”没用，得实测。最直接的方式是在每个类的 __init__ 开头加一行打印，例如 print(f"[{self.__class__.__name__}] init start")，然后实例化子类观察输出顺序是否匹配 C.mro() 结果（去掉最后的 object）。
另一个关键验证点是：链上每个类的 super().__init__() 是否都执行到了。如果某处漏掉这行，MRO 就会在那里中断，后续类不会被调用。注意，即使该类没有显式定义 __init__，Python 也会自动继承 object.__init__，所以仍需确认它是否被触发。
- 测试时用
print()或日志比单步调试更可靠，因为 MRO 行为依赖运行时类结构 - 检查是否有类意外继承了
object以外的基类（如Exception、dict），它们自带__init__且通常不调用super()，会截断链 - 若使用第三方库类作为父类，务必查文档确认它是否支持协作式初始化；不支持的类应放在 MRO 链末端，或通过组合替代继承
多重继承中 super() 和显式类名调用能混用吗？
不能安全混用。一旦你在某个类里写 A.__init__(self, ...)，就等于手动指定调用目标，绕过了 MRO 机制。此时后续的 super() 会从当前类的 MRO 下一个位置继续，而不是从 A 的下一个开始，导致调用顺序错乱甚至跳过某些类。
这种写法看似“可控”，实则在复杂继承树中极易失控。尤其当类被其他模块复用、MRO 因新增父类而改变时，硬编码调用会立刻失效。
- 所有协作式初始化必须全程使用
super()，包括最顶层基类（哪怕它只是object） - 如果真要跳过某层（比如完全替换某个父类行为），应该重构为组合，或用明确的钩子方法（如
_setup_xxx()），而不是在__init__里硬调 - 静态分析工具（如
pylint）可以配置检查super()调用缺失，建议启用missing-super-argument类规则
真正难的不是写出符合语法的 super() 调用，而是让整个继承体系里的每个类都理解并遵守同一套协作契约——参数兼容、调用连续、无硬编码跳转。一旦其中一环脱节，MRO 就会静默失效，问题往往延迟到运行时才暴露。
