17370845950

super().__init__() 在多继承中报错主因是 MRO 链上某类 init 签名不匹配（如需参数却传空），而非方法不存在；应统一用 **kwargs 并确保每层 super() 调用完整。

super().init() 在多继承中为什么会调用到不存在的方法

当 super().__init__() 触发 MRO（Method Resolution Order）链上某个类的 __init__ 时，如果该类没定义 __init__，Python 会继续向上查找；但如果 MRO 中某处跳到了一个只接受特定参数、而你传了空参或错参的父类，就会直接抛 TypeError: __init__() missing X required positional argument。这不是“找不到方法”，而是“找到了，但签名不匹配”。

常见诱因：

• 混用了带参 __init__ 和无参 __

  

  init__ 的父类，且 MRO 把带参类排在了无参类之后
• 某个父类的 __init__ 被意外覆盖或未正确调用 super().__init__()，导致参数流中断
• 手动写死了 Parent.__init__(self)，绕过 super，破坏了协作式调用链条

如何快速验证当前类的 MRO 是否合理

运行 print(YourClass.__mro__) 是最直接的方式。重点看三点：

• 所有参与多继承的父类是否都出现在序列中（顺序不能靠猜）
• object 必须在最后——如果它出现在中间，说明某个父类没走 super() 或用了经典类（Python 2 遗留问题）
• 如果有多个父类定义了 __init__，它们的相对位置是否符合你预期的初始化依赖关系（比如数据库连接类应在配置类之后初始化）

示例：class A(B, C): pass 的 MRO 不一定是 B → C → object，实际是 A → B → C → object（前提是 C 在 B 的 MRO 中未出现过），但若 B 继承自 C，MRO 就变成 A → B → C → object —— 这时 C.__init__ 只会被调用一次，由 B 的 super() 触发，而非 A 的。

修复 super().init() 崩溃的最小改动原则

不要重写整个继承结构，优先做三件事：

• 所有参与多继承的类，__init__ 必须显式接受 **kwargs，并在末尾调用 super().__init__(**kwargs)（哪怕自己不处理参数）
• 在最顶层（或第一个真正需要参数的类）里做参数解包，例如：config = kwargs.pop('config', None)，避免把未知参数传给 object.__init__()
• 检查每个父类是否真的需要 __init__：如果只是用来共享方法，删掉空的 __init__ 反而更安全（否则它会截断 super() 链）

错误写法：class Mixin: def __init__(self): pass —— 它没有 super()，会终结调用链；正确写法：class Mixin: def __init__(self, **kwargs): super().__init__(**kwargs)。

为什么 print(super()) 看不出问题，但运行就崩

super() 本身是个代理对象，不执行任何逻辑，只有当你调用它的属性或方法（如 super().__init__()）时才动态查 MRO。所以 print(super()) 永远不会报错，也无法反映参数传递是否断裂。

真正危险的是“静默跳过”：某个类的 __init__ 因为没写 super() 或参数不匹配，导致后续父类完全没被初始化。这类问题往往在访问某个属性时报 AttributeError，而不是在构造时崩溃，更难定位。

最容易被忽略的一点：子类重写了 __init__ 却忘了加 **kwargs，哪怕只有一行 print("init")，也会让整个协作链失效——因为它的签名和父类不兼容，super() 查找时可能跳过它，也可能卡在它这里报错。