在网络上的Python教程里“新式类New-style Class”这个词出现的频率越来越低因为Python 3里所有类都是新式类再也没人需要做选择题。但了解它尤其是绕着钻石继承和MROMethod Resolution Order方法解析顺序深挖一遍对整个继承体系都会通透很多。有个阶段我觉得自己挺懂继承的直到某次调试一段多重继承代码发现调用链诡异到完全不符合直觉打印出__mro__那一刻才恍然大悟所有“玄学”背后都有一套严格的线性化规则在兜底。这篇文章就把这条线彻底捋清楚新式类带来了什么钻石继承为什么棘手C3线性化算法是怎么算出MRO的以及super()到底是怎么“沿着MRO走”的。1. 先识破新式类的“新”Python类体系的一次大统一1.1 Python 2时代的两类类Python 3的彻底统一要理解新式类得先回到Python 2那个分裂的年代。当时你写class A:创建的是一个“旧式类”classic class它本质上是个独立的、和被叫作type的内置类型体系并不兼容的东西。而如果你写class A(object):得到的就是“新式类”它显式继承了内置的object。Python 3发布后所有类默认继承object旧式类彻底退场语法上再也写不出旧式类了。那为什么还要了解这个概念因为新式类不只是“自动加了object作为基类”它在底层统一了两套机制类与类型从那个时候起不再是两个世界的东西一切类都是type的实例一切实例也都有共同的祖先object。只有理解了这个统一才能解释后来__slots__、描述符协议、property、super()这些新机制为什么能正常工作。在新式类体系里你可以放心地做这些操作用type(instance) is 某个类、给类设置__slots__、用staticmethod/classmethod装饰器、触发__getattribute__等特殊方法。这些在旧式类中大多缺失或者行为不一致。1.2 新式类与MRO的关系为什么算法升级是“新”的核心新式类带来的众多变化中和这篇主题最相关的是方法解析顺序。旧式类查找方法时用的是简单的深度优先、从左到右的规则。这在直线继承里没问题一旦遇到菱形继承就会出现“基类方法被重复访问”“分支覆盖被跳过”之类的情况。新式类改用C3线性化算法来计算MRO解决了这两个毛病。判断一个类是不是新式类在Python 3环境里不必费劲。如果你是在维护Python 2的老代码看到某个类继承链的最顶端是object它才是新式类。另外有个快捷观察点新式类可以直接通过类名.__mro__拿到MRO元组旧式类没有这个属性只有__mro__不存在的旧式类会用别的查找方案。2. 钻石继承多继承里最经典的“菱形陷阱”2.1 菱形继承长什么样它为什么必然出现钻石继承也叫菱形继承形态非常直观A / \ B C \ / D用代码写就是这样class A: def who(self): print(A.who) class B(A): def who(self): print(B.who) class C(A): def who(self): print(C.who) class D(B, C): passD同时继承了B和C而B、C都来自A继承结构图里就出现了一个菱形。这种结构在真实项目里一点也不罕见尤其是做Mixin混入类设计的时候。你会把可复用的逻辑拆成一个个小类然后组合成一个综合类类与类之间经常共享同一个基类。比如一个MixinA、一个MixinB它们各自又继承自同一个Base最终被某个业务类同时继承这类结构一多菱形就到处是。2.2 旧式类的深度优先查找两个致命问题旧式类在解析D的方法时采用深度优先的顺序D - B - A - C - A。这个顺序看起来是“先一路走到头”但暴露了两个致命问题。第一个问题是A在查找路径里出现了两次。调用D实例的方法时如果B和C都没有覆盖A的方法D最终找到的是A.who但这趟查找把A“路过”了两遍。如果这是一个初始化操作比如__init__那完全可能重复初始化一个共享对象两次造成不必要的开销甚至引发状态错乱。第二个问题更隐蔽也更致命如果C对A.who做了覆盖而这又是你期望的最终行为深度优先算法会完全跳过这个覆盖。因为查找顺序是D - B - A走到A就找到了目标方法不会继续检查C。结果就是C的定制逻辑被静默忽视了。这种“我明明覆盖了基类方法却完全没生效”的现象在项目里排查起来非常恼人。2.3 新式类的C3算法把“重复”和“跳过”都消灭了新式类改用的C3线性化算法在解析D的MRO时得出顺序是D - B - C - A - object。这条链上A只出现一次C对A的覆盖能被正确找到同时B的所有父类依旧在C的父类前面。C3的核心追求有三个每个祖先类在MRO中只出现一次避免重复调用。子类永远排在父类前面保证“子类优先”的直觉。保持父类的局部顺序不被打破这叫“单调性”即如果一个类在某个父类的MRO里排在另一个类前面那在所有子类的MRO里它也要排前面。这三条让多重继承的行为变得符合直觉你想覆盖逻辑的类写在前面就真的会先生效。3. 手把手拆解C3线性化MRO是怎么被算出来的3.1 三个基础规则先列出来再去mergeC3算法对一个类C的MRO计算遵循以下流程先取C自己然后合并所有父类的MRO列表以及父类列表本身。合并过程中依赖三个规则线性化结果从类自身开始。每个父类的MRO列表需要作为整体参与合并父类内部顺序不变。合并时对每个列表从头到尾扫描头元素如果某个头元素没有出现在任何其他列表的尾部即除第一个位置以外的位置就取它否则跳到下一个列表的头元素检查。如果不理解第三点直接看推导比看定义快得多。3.2 推导D(B, C)一步一步算给你看还是用class D(B, C)并且B extends A、C extends A这个场景。先写出基础MROL(A) A - object L(B) B - merge(L(A), [A]) B - A - object L(C) C - A - object对D而言L(D) D - merge(L(B), L(C), [B, C]) D - merge([B, A, object], [C, A, object], [B, C])merge第一轮扫描第一个列表的头是B检查B是否出现在其他任意列表的尾部。第二个列表[C, A, object]没有B第三个列表[B, C]的尾部是[C]也没有B。B满足条件取出来。现在L(D) D - B剩下列表为[A, object]、[C, A, object]、[C]。继续扫描新第一个列表的头是A但要检查A是否出现在其他列表尾部。第二个列表[C, A, object]的尾部是[A, object]A在里面。条件不满足不能取A。看第二个列表的头C检查C是否出现在其他列表尾部。第三个列表[C]的尾部是空不包含C第一个列表[A, object]也没有C。满足条件取C。现在L(D) D - B - C剩下两个列表都是[A, object]。继续两个列表头部都是A且A也不在其余尾部取出A。最后只剩下object。最终结果L(D) D - B - C - A - object在Python里验证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)这个结果干净利落地说明了前文提到的所有改进C在B之后、A之前A只出现一次。3.3 复杂一点的推导E(D, C)情况下怎么走再叠一层比如class E(D, C): pass此时L(D) D - B - C - A - object L(C) C - A - object L(E) E - merge(L(D), L(C), [D, C]) E - merge([D, B, C, A, object], [C, A, object], [D, C])第一轮扫描第一个列表头D检查D是否在其他列表尾部出现第三个列表[D, C]尾部是[C]没有D第二个列表也没有D。取D。剩下E - D继续合并[B, C, A, object]、[C, A, object]、[C]。再扫描第一个列表头B其他列表尾部没有B取B。剩下E - D - B继续合并[C, A, object]、[C, A, object]、[C]。继续头元素C没有出现在其他尾部取C。然后就是A、object。最终L(E) E - D - B - C - A - object这种层层展开的推导方式在复杂类层次里完全够用而且每一步都能验证保证父类MRO作为一个整体被插入父类内部顺序不变。3.4 当C3算不出来TypeError就是一个证据既然C3算法是“取不出合法头元素就报错”那它天然可以检测出“坏”的继承顺序。比如class X: pass class Y: pass class A(X, Y): pass class B(Y, X): pass class C(A, B): pass这个例子里A的MRO是A - X - Y - objectB的MRO是B - Y - X - object。要让C继承A和BC3算法要求X和Y同时满足“X在Y前”“Y在X前”的矛盾条件于是直接抛出TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y。这个报错其实就是算法的自我保护机制与其给出一个行为随机的MRO不如直接拒绝创建类。更多的时候这个报错出现在你调整多个父类的顺序时例如class C(B, A)这种写法也可能触发矛盾。看到这类错误不要慌查一下几个基类的__mro__就能定位。4. super()的本质不是调用父类而是沿MRO接力4.1 super()返回的是一个“代理”不是父类实例很多初学多继承的人对super()的理解停留在“亲切的父类快捷方式”。严格来说并不准确super()返回的是一个代理对象它本身不是父类实例但它会负责把方法调用转发到MRO中该类的“下一个类”。不要小看这个“下一个类”正是这个概念让多继承下的方法调用变得优雅。在Python 3里无参形式的super()是语法糖内部等价于super(当前类, self)。Python内部会利用__class__这个隐式单元格来找到当前类再结合实例self的类型去查MRO找到当前类接下来的那个类。如果你在类外部想要“模拟”这种效果就得写super(D, d).who()之类的形式手动指定从D开始往MRO后面找。4.2 协作式多重继承的标准写法每个人都调super()多继承下要想让每个类的方法都被执行到需要“协作式多重继承”的写法。核心只有一条参与继承链的每个类在方法体里都调用super()而不是调用某个具体的父类方法。看个经典例子class A: def who(self): print(A.who ) class B(A): def who(self): print(B.who - , end) super().who() class C(A): def who(self): print(C.who - , end) super().who() class D(B, C): def who(self): print(D.who - , end) super().who()D的MRO是D - B - C - A - object调用D().who()输出D.who - B.who - C.who - A.who整个过程就像一场接力赛D调用super().who()去MRO里找D的下一个类也就是BB再调用super().who()去MRO里找B的下一个类就是CC接着传给AA再调用super().who()时MRO里A下一个已经到objectobject没有who方法于是报AttributeError所以在实际设计里A通常不调用super().who()或者要提前判断一下。这是多继承协作式设计的关键链上每个方法都想继续往后传但链条的终端类要负责“停住”。4.3 常见误区别写死父类名我看过不少代码在B.who里调用的是A.who(self)。单继承下这没问题一旦放进上面的菱形结构里协作就被破坏了。如果B写死调用A那C就被跳过了C.who永远不会执行你可能排查半天都不知道原因。还有一点协作式__init__需要参数一致。因为super().__init__()会沿着MRO把后面的__init__全部调用一遍如果你在某个类里给__init__加了新参数但后继类没有兼容处理就会报错。比较常见的处理方式有两种要么所有类都用*args, **kwargs兜底并显式取出自己需要的参数要么保持所有__init__签名足够一致。这里没有银弹按项目规模选一种并坚持就好。5. 实战排查与工程建议5.1 把__mro__当作第一排查工具遇到继承调用行为不符合预期第一件事永远是打印类名.__mro__不要靠猜。我自己的调试习惯是写一个极小的脚本把层次结构单独抽出来跑一遍断点打在关键方法入口然后看控制台输出的调用顺序。配合__mro__问题顺序一目了然。有时候你还需要用类名.__bases__看直接父类用isinstance/issubclass验证关系。这些都是标准内省能力比肉眼盯代码可靠得多。5.2 设计多重继承时的几条野路子经验搞过几个用到Mixin的项目以后我总结了几个自己的“约定”不一定是教科书标准但实战里确实少踩坑把被动的基类写在继承列表最后面。class D(B, C, Base)和class D(Base, B, C)的MRO可能完全不同把Base放最后一般更安全因为基类的方法最容易被后面的类覆盖。尽量让钻石继承扁平化。如果类层次可以设计成“每个直接父类都直接继承object”那MRO会简单很多不会有太深的递进排查也容易。任何参与多继承的类都要有协作意识。要么全部用super()要么全部不用尽量不要混用。混用有时候能跑但一旦出问题逻辑就会显得极其混乱。警惕顺序调整引发TypeError。多父类的继承顺序不是随便排的改一个父类的顺序可能导致C3算不出来开发环境里尽早暴露比部署后再发现好。5.3 几句话速查症状原因解决思路子类覆盖的方法被跳过旧式类思维下的继承顺序问题写死了父类名打印__mro__确认路径改用super()TypeError: Cannot create a consistent MRO两个父类的MRO顺序矛盾调整父类顺序或重新设计类层次super()调用中断链上某个类没调用super()链条断了检查协作式写法确保每层都调用super()__init__参数冲突某个类的__init__加了新参数后继类不兼容统一参数签名或使用*args, **kwargs协调结尾一点个人心得新式类的MRO在没有遇到多继承之前几乎感受不到它的存在但一旦进入钻石继承的领地它就成了唯一的裁判。我自己踩过几次坑之后养成了两个习惯第一任何稍微复杂一点的继承结构先不写业务逻辑直接把类定义和小测试脚本写出来打印__mro__校准预期第二永远默认使用super()而不是父类名。这个习惯让重构时移动继承顺序的代价变得很低因为调用链是动态解析的不会因为某个类名写死而崩掉。Python的继承体系设计得并不过分玄妙一切都有规则、可推导把C3线性化搞明白多重继承对你来说就不再是“看着能跑”的运气活而是每一步都有迹可循的确定性工程。