问题的答案。
在 Python 2.3 之前，方法解析依赖于深度优先、从左到右的搜索，这在钻石继承模式中产生不一致的结果。采用了C3线性化算法，最初为Dylan编程语言开发，以替代这种方法。它提供了一种数学上严格的排序，尊重继承图和基类的声明顺序。
在多重继承场景中，我们需要一个确定性的线性化，其中父类总是在子类之前，并且在所有层级中保持从左到右的声明顺序。算法还必须保持单调性，这意味着如果类 A 在父类的 MRO 中位于类 B 之前，则这种顺序不能在任何子类中被逆转。某些继承声明会产生逻辑矛盾，使这些约束发生冲突，从而使有效的线性化变得不可能。
C3 通过合并所有父类的线性化与父类自身的列表来计算 MRO。该算法递归选择这些列表中第一个头部，该头部不出现在其他任何列表的尾部，确保没有类被放置在其先决条件之前。如果在任何步骤中不存在有效的头部，Python 将引发 TypeError，表示方法解析顺序不一致。
class A: pass class B(A): pass class C(A): pass class D(B, C): pass # D.__mro__ 计算为: merge(L(B), L(C), [B, C]) # 结果: (<class 'D'>, <class 'B'>, <class 'C'>, <class 'A'>, <class 'object'>) print(D.__mro__)
生活中的例子
我们正在构建一个数据处理框架，使用混合类来添加诸如日志记录和验证等跨切关注点。我们的基类 DataProcessor 提供核心功能，而 LoggingMixin 和 CacheMixin 都从 BaseComponent 继承以共享实用工具。当具体类将这些混合类组合时，我们遇到了初始化顺序错误，导致缓存发生在日志记录之前，并且 BaseComponent 方法在不同的具体实现中解析不一致。
考虑的第一个解决方案是在每个具体类中手动链接方法，明确地调用 LoggingMixin.process()，然后在硬编码的顺序中调用 CacheMixin.process()。这种方法提供了对执行顺序的明确控制，消除了 MRO 不确定性。但是，它违反了 DRY 原则，将依赖知识分散在整个代码库中，当需要重新排序时造成维护噩梦，并绕过动态调度系统，破坏了多态性。
第二种方法是使用显式的 super(LoggingMixin, self) 调用具有命名类，而不是零参数 super()。这允许在解析链中精确控制下一个父类是哪个，而不管 MRO 是怎样的。尽管这样做有效，但它极为脆弱，因为重命名类需要更新每一个 super() 调用，并且完全破坏了 Python 的自动线性化，使代码与将来的混合类添加不兼容，而无需进行广泛的重构。
第三种方法采用 C3 线性化，通过声明继承为 class Pipeline(LoggingMixin, CacheMixin, DataProcessor)，并实现协作多重继承，每个混合类的 init 调用 super().init()。这使得 MRO 自然确定 LoggingMixin 在 CacheMixin 之前，同时将 DataProcessor 保持在最后。该解决方案尊重了 Python 的继承语义，不需要硬编码类引用，并允许框架通过简单地更新类头部自动适应新的混合类。
我们选择了第三个解决方案，因为它符合 Python 的设计哲学，而不是与其对抗。通过利用零参数 super()，每个混合类可以将初始化控制传递给 MRO 中的下一个类，而无需知道那个类是什么，从而实现真正的组合性。类声明中的显式顺序使优先关系可见且易于维护。
结果是一个强大的框架，支持超过三十种处理器变体及各种混合组合。开发人员可以声明性地创建新的管道类型，而无需担心初始化顺序错误。C3 通过在类定义时引发 TypeError 来防止架构错误，当开发人员试图创建不一致的继承模式时，在开发阶段捕捉逻辑矛盾，而不是在生产中。
候选人常常忽视的内容
为什么 Python 的 C3 线性化算法拒绝某些多重继承层次结构并出现 "无法创建一致的方法解析顺序" 错误，如何在不修改基本继承要求的情况下解决这一问题？
当优先约束形成一个逻辑矛盾时，算法会拒绝层次结构，这种矛盾没有任何线性化可以满足。这发生在一个父类要求类 X 在类 Y 之前，而另一个父类要求 Y 在 X 之前，从而形成一个不可解决的循环。要在不移除必要关系的情况下修复此问题，您必须使用组合而不是继承对其中一个冲突分支进行重构，或者将公共功能提取到两个父类所继承的共享基类中，从而打破优先级循环，同时保留接口。
在方法内部使用时， Python 的零参数 super() 如何实际确定下一个要搜索的类是哪个，为什么这与复杂继承图中的显式 super(CurrentClass, self) 不同？
零参数 super() 使用 class 单元变量（被方法定义闭合）和实例的 mro 在运行时动态查找下一个类。它在 MRO 中找到当前类，然后返回下一个类的代理。与显式的 super(CurrentClass, self) 不同，它静态地指定起始点；如果方法被子类继承，显式形式仍然从 CurrentClass 开始，可能会跳过子类实际 MRO 中的类，而零参数 super() 则自动适应以继续从当前实例层次中的方法定义类。
在 C3 线性化中，单调性属性是什么，为什么它对保持子类化现有多重继承层次结构时可预测的行为至关重要？
单调性保证如果类 A 在父类的 MRO 中位于类 B 之前，则 A 在所有该父类的子类中始终位于 B 之前。这防止了旧的深度优先算法中的 "阴影重排序" 错误，在这种情况下，添加子类可能会意外反转两个无关父类之间的优先级。没有这个属性，向类添加新的混合类可能会改变现有父类的相对排序，导致父类与子类中的方法以不同顺序执行，从而在大型继承树中导致微妙的行为回归。