super()调用失效的主因是某父类__init__漏调super().__init__()导致MRO链中断；所有参与MRO的类若定义__init__，都必须显式调用super().__init__()，且应统一用super()而非硬编码父类名，参数传递需保持签名一致并推荐用**kwargs。
super() 调用不生效？先确认你没在 __init__ 里漏掉 super()
多重继承下 super() 失效，最常见的原因是某个父类的 __init__ 忘了调用 super().__init__()，导致 MRO 链在中途断掉。Python 不会报错，但后续类的初始化被跳过。
比如 A → B → C（MRO 为 [A, B, C, object]），若 B.__init__ 没写 super().__init__()，C.__init__ 就永远不会执行。
- 所有参与 MRO 的类，只要定义了
__init__，都必须显式调用super().__init__()（哪怕只是空实现） - 不要混用显式类名调用（如
B.__init__(self)）和super()，这会破坏协作机制 - 用
A.mro()查看实际顺序，别靠手算 —— 特别是钻石继承时，C3 算法结果常反直觉
为什么 super().__init__() 有时传参失败？
super() 本身不决定参数个数，它只把调用转发给 MRO 中下一个方法。参数是否匹配，取决于整个继承链上所有同名方法的签名一致性。
常见报错 TypeError: __init__() takes 2 positional arguments but 3 were given，说明某一级方法只接受 self，但上游多传了一个参数。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 推荐做法：所有中间类的
__init__接收**kwargs，并把未消费的参数传给super().__init__(**kwargs) - 避免在中间层强制限定参数数量，除非你 100% 控制整条链
- 如果必须校验参数，放在最顶层基类或具体子类中，而不是中间协作层
多重继承中，super() 和直接调用父类名的区别在哪？
直接写 Parent.__init__(self) 是硬编码调用，完全绕过 MRO；而 super() 是动态查找 MRO 中「当前类之后」的下一个实现 —— 这是协作式设计的核心。
例如两个父类都定义了 setup()，用 super().setup() 才能保证两者都被调用；用 ParentA.setup(self) 就永远跳过了 ParentB.setup()。
-
super()在普通方法、__init__、__new__甚至描述符中都适用，行为一致 - 在类方法中要用
super(cls, cls).method()，否则默认绑定实例 - 静态方法不能用
super()—— 它没有隐式self或cls，找不到上下文
如何验证 super() 真的按 MRO 走完了？
光看代码逻辑容易误判，尤其涉及 mixin 类或第三方库时。最可靠的方式是运行时打点。
在每个可能参与协作的方法里加一行日志：print(f"{self.__class__.__name__}.method called")，然后触发调用，观察输出顺序是否与 MyClass.mro() 一致。
- 注意：
super()的「下一个」是相对于当前类在 MRO 中的位置，不是相对于调用它的那个类 - 如果某个方法没被打印，说明它没被
super()链覆盖到 —— 很可能是该类没定义这个方法，或定义了但没调super() - 调试时临时把
super()替换为print("next:", type(super()).__mro__)可直观看到当前委托目标
MRO 协作不是“写了 super() 就万事大吉”，而是整条链上每个环节都得配合。最容易被忽略的是：你引入的一个小 mixin，可能因为没写 super()，悄悄切断了整个初始化流程。
