Python的MRO严格按C3线性化算法计算，顺序唯一可预测，必须通过__mro__或mro()查看；super()指向MRO中当前类的下一个类，行为依赖调用上下文与MRO位置。
Python的MRO到底按什么顺序查找方法
Python多重继承的方法解析顺序不是简单的“从左到右”或“深度优先”，而是严格由C3线性化算法计算出的唯一、可预测的序列。你调用 obj.method() 时，解释器会沿着这个序列逐个检查类，直到找到第一个定义了该方法的类为止。
关键判断：不能靠直觉猜顺序，必须查 ClassName.__mro__ 或 ClassName.mro() —— 这是唯一可信的依据。
为什么super()有时跳过父类，有时又不跳
因为 super() 不是指“直接父类”，而是指 MRO 中当前类的下一个类。它的行为完全依赖于调用上下文（即当前所在类）和该类在 MRO 中的位置。
常见错误现象：super().__init__() 在多个混入类中被重复调用，或某个父类的 __init__ 根本没被执行 —— 往往是因为 MRO 序列里它被更早的类“挡住了”，或者你误以为 super() 总是往上走一层。
立即学习“Python免费学习笔记（深入）”；
- 使用场景：只有所有参与继承的类都一致使用
super()（且参数签名兼容），C3 才能保证每个__init__被调用一次 - 参数差异：如果某个类的
__init__接收额外参数，而super().__init__()又没传过去，就会报TypeError: __init__() takes X positional arguments but Y were given - 性能影响：C3 计算在类定义时完成，运行时无开销；但错误的 MRO 会导致逻辑错误，比性能问题更难排查
手动推导C3线性化的实用技巧
虽然 Python 自动算好 MRO，但调试时手推能快速定位冲突根源。核心规则就三条：保留本地优先、保持子类先于父类、合并时各父类的相对顺序不变。
例如：class D(B, C): pass，其中 B 继承自 A，C 也继承自 A，那么 D.mro() 必须满足：D 在最前，A 在最后，且 B 在 C 前（因声明顺序），同时 B 的父类 A 和 C 的父类 A 合并为一个。
简短示例：
class A: pass class B(A): pass class C(A): pass class D(B, C): pass print(D.__mro__) # → (<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
若把 D 改成 class D(C, B): pass，则 B 和 C 在 MRO 中位置互换 —— 顺序真的只取决于括号里的声明次序。
遇到“Cannot create a consistent method resolution order”怎么办
这是 C3 算法失败的明确信号，说明你写的继承结构存在逻辑矛盾，Python 拒绝妥协。典型诱因是菱形继承中某条路径改变了父类间的相对顺序。
常见错误现象：定义类时报 TypeError: Cannot create a consistent method resolution order (MRO) for bases ...
- 使用场景：当你混合多个第三方 mixin 类，或自己设计多层抽象基类时最容易触发
- 排查步骤：逐个简化继承列表，用
print(BaseClass.__mro__)观察每一步的 MRO；重点检查有没有两个类，它们各自的父类序列对同一组祖先类提出了互相冲突的排序要求 - 根本解法：要么重排继承声明顺序，要么拆分功能、避免让同一个祖先类从不同路径被引入两次（比如改用组合而非继承）
MRO 看似是继承的副产品，实则是 Python 多重继承能否成立的前提——它不声不响，但一旦出错，连类都定义不了。
