mro是只读元组属性，由c3线性化算法在类定义时确定唯一顺序，super()据此动态查找下一个类；d.__mro__为(d,b,c,a,object)因c3强制子类优先、父类声明序优先且保持各父类mro相对位置。
<strong>mro</strong> 不是方法，是只读元组属性，它直接暴露 Python 的方法解析顺序结果。Python 3 用 C3 线性化算法算出这个顺序，不是靠“处理”菱形继承，而是从一开始就不允许歧义存在——D 类的 <strong>mro</strong> 永远是确定的、唯一的线性链。
为什么 D.__mro__ 是 (D, B, C, A, object) 而不是 (D, B, A, C, object)？
C3 算法强制要求：所有父类的 MRO 必须被“合并”，且满足三个约束：
- 子类总在父类之前
- 各父类声明顺序（class D(B, C) 中 B 在前）优先级更高
- 每个类在最终序列中只出现一次，且保持其自身 MRO 中的相对位置
这意味着：
- B 的 MRO 是 (B, A, object)
- C 的 MRO 是 (C, A, object)
- 合并时，A 不能提前出现在 C 之前（否则违反 C 自身的 MRO），所以 A 必须排在 B 和 C 都之后
super() 在菱形结构里到底调谁？
super() 不找“父类”，它按 __mro__ 当前位置往后找下一个类。关键点在于：
- super() 的行为完全依赖于调用它的**实例类型**和**当前所在类**，不是写在哪就固定调谁
- 在 B.ping() 里写 super().ping()，实际查的是 B 在 D.__mro__ 中的下一个类，也就是 C，不是 A
常见错误现象：
- 直接调 A.ping() 硬编码，绕过 MRO，破坏协作初始化
- 在 B.__init__() 里漏掉 super().__init__()，导致 C 和 A 根本不执行
- 把 class D(C, B) 写反顺序，__mro__ 变成 (D, C, B, A, object)，super() 行为全变
怎么验证你写的菱形继承没踩坑？
别只看 print(D().ping()) 输出，要动手查真实链条：
- 执行 print(D.__mro__)，确认顺序符合预期
- 在每个类的 __init__ 或方法里加 print(self.__class__.__name__)，观察实际调用流
- 如果有参数传递，确保所有 super() 调用签名一致（比如都接受 **kwargs），否则中途会报 TypeError
性能影响几乎为零——__mro__ 在类定义时就计算好并缓存，运行时只是元组索引查找。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
真正容易被忽略的是：MRO 是类的属性，不是实例的；改了类继承关系必须重启解释器或重载模块，热修改 <strong>bases</strong> 不会自动重算 <strong>mro</strong>。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
