__mro__是Python中类的只读属性，表示方法解析顺序元组，由C3线性化算法在类定义时静态生成，首项为该类本身、末项为object，中间按算法重排父类顺序，并非简单继承声明顺序；它决定方法查找路径，而非继承关系图，仅适用于类对象，实例无此属性。
直接看 __mro__ 就能知道 Python 查找方法时的顺序，但它不是继承关系图，而是解析方法调用时的实际搜索链 —— 用错地方会误判类行为。
什么是 __mro__？它和继承树不是一回事
__mro__（Method Resolution Order）是 Python 在调用实例方法时，按顺序搜索父类的元组。它由 C3 线性化算法生成，不是简单按继承声明顺序拼接，尤其在多重继承下容易反直觉。
- 它只反映 方法查找路径，不表示“谁继承了谁”的静态关系
-
object总是末尾，哪怕你没显式继承它 - 手动修改
__mro__会报TypeError: can't set attributes of built-in/extension type 'type'
怎么安全地查看一个类的 __mro__
直接读取属性即可，但要注意对象类型：只有 class 对象有 __mro__，实例没有。
- ✅ 正确：
MyClass.__mro__、type(obj).__mro__ - ❌ 错误：
obj.__mro__（会抛AttributeError） - 输出是
tuple，可转为 list 方便打印：list(MyClass.__mro__)
示例：
立即学习“Python免费学习笔记（深入）”；
class A: pass class B(A): pass class C(A): pass class D(B, C): pass <p>print(D.<strong>mro</strong>)</p><h1><class '<strong>main</strong>.D'> <class '<strong>main</strong>.B'> <class '<strong>main</strong>.C'> <class '<strong>main</strong>.A'> <class 'object'>
为什么有时 __mro__ 和你写的继承顺序对不上？
C3 算法会重排以满足两个约束：子类优先、各父类相对顺序不变。一旦出现菱形继承或多个共同父类，顺序就可能“跳过”你预期的类。
- 比如
class E(C, B): pass，即使B和C都继承A，E.__mro__仍保证C在B前，且A只出现一次 - 若父类列表里有不兼容的 MRO（如某父类的 MRO 无法合并），定义类时直接报
TypeError: Cannot create a consistent method resolution order (MRO) - 用
super()时实际走的就是__mro__链，不是往上一层那么简单
调试时别只盯着 __mro__，还要结合 help() 和 inspect.getmro()
__mro__ 是只读属性，但 inspect.getmro(cls) 功能等价，适合写工具函数；而 help(cls) 在交互式环境里会把 MRO 和方法来源一起列出来，更直观。
-
inspect.getmro(cls)返回 tuple，和cls.__mro__完全一致，但语义更清晰 -
help(D)会在 “Method resolution order:” 下列出完整路径，还标出每个类定义的位置 - 如果某个方法没按预期调用，先确认它是否真在
__mro__某个类里定义 —— 有时候是拼写错误或被覆盖了
真正麻烦的是动态修改类结构（比如 monkey patch 或 metaclass 注入），这时 __mro__ 不会自动更新，得靠 class.__subclasses__() 或重新加载模块来验证。
