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() 查找时可能跳过它，也可能卡在它这里报错。