直接调用父类名会破坏菱形继承的初始化顺序，因强行跳过MRO导致A.__init__重复执行、C.__init__被跳过及super()链中断；应统一用super()配合**kwargs透传参数，并验证D.__mro__确保顺序正确。
为什么直接调用父类名会破坏菱形继承的初始化顺序
在菱形结构中（如 D(B, C)，而 B 和 C 都继承自 A），如果某个类里写 A.__init__(self)，就等于强行跳过 MRO，把控制权固定交给 A。这会导致：同一层级的其他类（比如 C）被跳过、A.__init__ 被重复执行、甚至 super() 链在上游中断。
常见错误现象：
- 创建
D()实例时，A.__init__打印两次 -
B.__init__执行了，但C.__init__完全没触发 - 报错
TypeError: object.__init__() takes exactly one argument (the instance)（因参数未透传）
如何验证当前类的MRO是否符合预期
Python 的 C3 线性化算法不是凭空猜的，它有确定的计算规则，且结果可查。关键是要确认你写的继承顺序（如 class D(B, C):）是否真的生成了你想要的查找路径。
实操建议：
立即学习“Python免费学习笔记（深入）”；
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 直接打印
D.__mro__—— 它返回一个 tuple，顺序就是实际调用链 - 注意：MRO 必须满足三个约束：子类优先、各父类原有相对顺序保留、单调性（不出现“绕回”）
- 如果
D.__mro__里A出现在B和C之后，但你期望它更早被初始化，说明继承声明顺序错了（应调换B和C位置） - 不要依赖“深度优先”直觉；C3 不是 DFS，而是合并多个有序列表的确定性算法
super() 在 __init__ 中必须配合 *args, **kwargs 使用
菱形结构下，不同父类的 __init__ 参数往往不一致（比如 B 要 b_val，C 要 c_val）。若不统一参数协议，super().__init__() 会因参数不匹配而崩。
正确做法：
- 所有参与多继承的类，
__init__都应接受**kwargs，并原样传给super() - 具体参数由最末端的类（如
D）解析后注入，中间层只做透传 - 避免在中间类里写死参数名，比如
super().__init__(x=1)—— 这会覆盖下游需要的其他参数 - 顶层基类（如
A）也应写super().__init__(**kwargs)，即使它没有父类；否则链会在那里断掉
什么时候该放弃多重继承，改用 Mixin 或组合
菱形问题本身能被 C3 + super() 消解，但前提是所有类都“守规矩”。现实中，引入第三方类、遗留代码或动态生成类时，很难保证它们支持协作式初始化。
容易踩的坑：
- 继承了一个不带
super()的旧类（比如某些 ORM Model），整个链就失效 - 两个父类都试图管理同一个资源（如打开同一个文件句柄），即便初始化只走一次，逻辑上仍冲突
- 调试时发现
D.__mro__正常，但行为异常 —— 很可能某处隐式修改了实例状态，和继承顺序无关 - Mixin 类名加
Mixin后缀不是语法要求，但它是强烈信号：这个类只提供方法，不维护状态，也不该被单独实例化
真正难处理的从来不是 MRO 计算本身，而是当某个父类悄悄绕过 super()、或在 __init__ 里做了不可逆操作时，你根本没法从 D 这一层修复它。
