写Python这么多年类属性和实例属性这两个概念加上MRO算法看起来都是教科书里最基础的内容可实际项目里真能把它们搞明白的人并不多。你随便搜一下“Python类属性”就会发现搜索结果里全是概念定义、代码片段但很少有人能讲清楚为什么通过实例给类属性赋值另一个实例访问时却还是旧值为什么多继承下同一个方法名会调用到“看起来不合理”的那个类为什么有些老代码用type(类名, (基类,), {...})创建类行为跟class关键字还不一样这些问题背后其实都指向同一件事Python的属性查找机制和MRO方法解析顺序是怎么设计的。这篇文章不是照搬文档而是我把这些年实际踩过的坑、调试过的线上问题、面试里被问倒过的细节全部串起来讲一遍。适合刚入门的读者把基础打牢也适合有几年经验的人重新梳理底层逻辑。1. 类属性与实例属性的核心概念与区别1.1 一切皆对象类本身也是对象要理解类属性首先得接受一个事实Python里的class关键字执行完之后得到的不是一张静态的结构图而是一个实实在在的对象。这么说有点抽象但你可以把类对象想象成一个模板工厂这个工厂本身也有自己的一块黑板黑板上贴着各种信息比如方法名、类变量、文档字符串。实例则像是从工厂里生产出来的具体产品每个产品在出厂时会被允许带上属于自己的贴纸。工厂黑板上的内容是所有产品共享的但你贴在自己产品上的贴纸只属于你自己。这块“黑板”在Python里其实就是一个字典保存在类的__dict__属性里。看下面这段代码class User: role visitor def __init__(self, name): self.name name def greet(self): return fhello {self.name} print(User.__dict__)输出里你会看到role存在greet也存在但name不存在。因为name是给实例用的它在每个实例自己的__dict__里。这个基础认知非常关键搞不懂这一点后面所有关于属性共享、遮蔽、修改的坑都会反复踩。1.2 类属性与实例属性作用域和生命周期的差异从作用域上看类属性是类级别的命名空间实例属性是实例级别的命名空间。生命周期也不同类属性在类定义完成时就存在直到进程结束或类被显式删除实例属性则跟着实例走实例被垃圾回收它也就没了。访问规则上Python给了一条很简单的约定实例访问属性时先查实例自己的字典查不到才去类里找。所以下面的代码能跑通class Config: timeout 30 c1 Config() c2 Config() print(c1.timeout) # 30实例字典里没有所以去类字典里找 print(c2.timeout) # 30这里c1.timeout并没有在自己的__dict__里创建键它只是“借用”了类的属性。你可以用vars(c1)验证一下输出是空的{}。这种借用的机制带来的一个直接后果是类属性对实例来说是只读的除非你主动给实例创建一个同名属性去遮蔽它。很多新手在这里犯迷糊就是因为分不清“读”和“写”。读的时候找不到就去类里找写的时候永远只在实例自己的字典里写。这种不对称设计是Python属性系统的核心也是后面所有坑的源头。类属性、类方法、静态方法这三者经常一起被讨论。类属性是数据类方法是用类作为第一个参数的方法静态方法是既不需要实例也不需要类的普通函数。它们最大的共同点就是都是定义在类命名空间里的成员访问方式也类似。但语义上差别很大后面我会专门展开。1.3 三个特别容易踩的赋值坑第一个坑实例赋值同名属性导致类属性被“遮蔽”。看代码class Counter: total 0 c Counter() c.total 10 print(c.total) # 10 print(Counter.total) # 0这里c.total 10并不会修改类的total而是在实例的字典里新建了一个键。你会发现实例字典里从此多了一个total类属性还在原地只是你的视线被实例属性挡住了。想清掉这个遮蔽可以用del c.total之后再次访问c.total又会回到类属性的值。这个行为在某些框架的字段缓存、动态属性场景里会引发很隐蔽的问题。第二个坑通过实例修改类属性要看是赋值还是原地修改。这句话很多人不理解其实关键看右边操作符。赋值操作符永远创建或更新实例属性但如果你操作的是一个可变对象比如列表、字典那情况完全不同class Registry: items [] r1 Registry() r2 Registry() r1.items.append(apple) print(r2.items) # [apple]两个实例看到的是同一个列表append没有在实例字典里创建键r1.items先解析到类属性然后对类属性指向的列表对象做原地修改所以所有实例都会看到变化。这个行为既是便利也是坑尤其是你把可变对象放在类属性里当默认值又希望每个实例有独立数据时。第三个坑self.xxx []和类属性同名时你以为在初始化默认值实际上是在给实例创建独立副本。这其实是第一个坑的延伸但很多人写成下面这样之后懵了class Task: tags [] def __init__(self): self.tags []这段代码的本意可能是“用类属性当默认值”但效果是每个实例都创建了独立的tags列表。不能说这不对只是你得清楚自己到底在做什么。想保留共享语义就只在类里操作想隔离副本就必须在实例上赋值。搞混这两者项目里就会出现“一个实例改了数据另一个实例跟着变”或者“明明类属性有默认值实例却拿不到”的诡异现象。2. 属性查找机制与__dict__的底层真相2.1__dict__到底存了什么Python里大多数对象都自带一个__dict__它是属性的真实存储空间。类的__dict__里能看到方法、类属性、特殊方法等实例的__dict__里只有实例属性。但要注意类__dict__里的键是mappingproxy类型的映射只读不能直接改实例__dict__则是普通字典可以随便改。这段代码能看出区别class A: x 1 def method(self): pass a A() a.y 2 print(type(A.__dict__)) # mappingproxy只读 print(type(a.__dict__)) # dict可写__dict__不仅能查看也能手动修改。比如a.__dict__[y] 3等价于a.y 3这在调试时很有用。但线上代码里请慎重使用因为你绕过了类定义时可能注册的校验逻辑。另外如果类定义了__slots__实例就没有__dict__了属性被限制在固定集合内这时候你再尝试访问不存在的属性报错信息也会跟普通类不一样。__slots__的核心目的是节省内存和限制属性名但代价是你失去了灵活性。2.2 属性查找顺序实例先查自己再沿着MRO逐级往上假设有这样一个继承链class A: value A class B(A): pass class C(B): pass c C() print(c.value) # Ac.value的解析过程是先查c.__dict__没有然后取type(c).__mro__也就是(C, B, A, object)依次查C.__dict__、B.__dict__、A.__dict__最后查到object.__dict__。整个链路里有一个非常关键的点实例的类本身也参与查找因此元类type的子类上的类属性也会被实例访问到只不过它排在类MRO的后面。这个细节在ORM、事件系统里偶尔会出现比如你给模型类加了一个元类属性结果所有实例都能访问到它。属性查找还有一个容易被忽略的阶段如果在类属性里发现了符合描述符协议的对象实现了__get__或__set__查找规则会改变。我后面会单独讲这里先记住大方向实例自身的字典优先级高类属性的数据描述符优先级更高。前者让你能遮蔽类属性后者让你无法遮蔽数据描述符。这听起来矛盾但它是Python特意设计的目的是让property这种特性具备强制约束力。2.3 描述符协议让类属性变得“不单纯”描述符是Python属性系统的幕后功臣。你天天写property其实就是在创建一个数据描述符。数据描述符是指同时定义了__get__和__set__或__delete__的对象它作为类属性出现时优先级高于实例字典。举个例子class Positive: def __get__(self, obj, objtypeNone): return self.value def __set__(self, obj, value): if value 0: raise ValueError(必须大于等于0) self.value value class Order: count Positive() order Order() order.count 5 print(order.count) order.count -1 # 报错order.count 5这一行正常理解是给实例字典添加键但由于count是数据描述符Python会优先调用描述符的__set__根本不会往实例字典里写东西。这就是为什么property能让一段校验逻辑在每次赋值时都生效。而只实现了__get__的非数据描述符比如普通方法函数优先级低于实例字典所以你能在实例上给方法“遮蔽”一个普通属性。理解描述符不是让你天天去写描述符而是帮助理解框架源码。比如Django的模型字段、SQLAlchemy的列对象底层都是描述符在控制属性赋值和读取。以后排查“为什么我实例属性明明赋值了读取的还是类里的东西”时第一反应应该是先查这个类属性是不是描述符而不是怀疑Python的赋值逻辑坏了。3. MRO算法演进从深度优先到C3线性化3.1 多继承与菱形问题多继承之所以复杂核心在于菱形结构。看下面这个经典结构class A: def who(self): print(A) class B(A): def who(self): print(B) class C(A): def who(self): print(C) class D(B, C): pass这里D同时继承B和C而B和C又都继承A继承关系图画出来就是一个菱形。问题来了调用D().who()到底应该执行B的还是C的如果B和C都没重写who那自然走到A但实际项目中往往每个类都定义了同名方法你总得给解释器一条确定的解析路径。这个确定路径就是MRO。为了让MRO有意义它必须满足几个直觉上的要求子类优先于父类多个父类之间按声明顺序保持相对顺序整个继承关系里不能有矛盾同一个类在一条MRO里只能出现一次。这些要求看起来简单但不同算法实现起来差别很大。3.2 Python 2.2之前深度优先搜索的致命缺陷在Python 2.2之前经典类的MRO用的是深度优先搜索DFS也就是沿着某个基类一路走到黑再回溯找下一个分支。DFS在单一继承下没问题但面对菱形结构会暴露一个严重的顺序问题看这个例子class A: def save(self): print(A save) class B(A): pass class C(A): def save(self): print(C save) class D(B, C): pass d D() d.save()DFS按D → B → A → C的顺序解析B里没有save紧接着就会在A里找到save并执行C的重写直接失效。你可能会说C本来在D(B, C)里顺序靠后被跳过也正常。但问题在于C明明覆盖了A的行为而B没有覆盖DFS却优先采用了A的实现这破坏了C的预期。这种问题的本质是DFS在回溯时把“较深的祖先”放在了“较晚的兄弟分支”之前破坏了父类之间的顺序约束。Python 2.2为了解决这个问题引入了新式类和新的MRO算法但第一版新式类的MRO在复杂多重继承下仍有其他问题直到2.3版本才正式采用C3线性化。3.3 C3线性化算法原理与手工计算C3线性化的名字来自论文Python从2.3开始用它来生成新式类的MRO。C3的核心合并规则是一个类的线性化等于类本身加上其所有父类线性化的merge结果。递归定义为L[C(B1, ..., Bn)] C merge(L[B1], ..., L[Bn], [B1, ..., Bn])merge操作的原则是从左到右取第一个列表的头部元素如果这个头元素没有出现在其他任意列表的尾部就把它取出来放入结果并同时从所有列表里删除它否则跳到下一个列表继续尝试如果所有列表都无法满足条件就抛出一个类型错误提示无法创建一致的MRO。拿菱形结构手工算一遍。定义class A(object): pass class B(A): pass class C(A): pass class D(B, C): pass基础线性化L[A] [A, object]L[B] [B] merge(L[A], [A]) [B, A, object]L[C] [C, A, object]。然后是L[D] [D] merge(L[B], L[C], [B, C])。带入merge输出为空候选列表是[B, A, object]、[C, A, object]、[B, C]。取第一个列表头B检查它是否出现在其他列表的尾部没有于是取出B后续合并变成merge([A, object], [C, A, object], [C])。取第一个列表头A发现它出现在第二个列表[C, A, object]的尾部所以跳过尝试下一个列表头CC没有出现在其他列表尾部取出C合并merge([A, object], [A, object])。接着取A检查A没有出现在其他列表尾部取出最后是object。最终L[D] [D, B, C, A, object]也就是D.mro()输出的顺序。注意这里的顺序是B在C前因为D(B, C)声明顺序如此而A被放到了两个父类的后面C重写的方法能被正确找到。如果D(B, C)改成D(C, B)MRO就反过来了。这个计算看起来复杂但Python的mro()方法都写好了你只要理解它的约束就行了。3.4__mro__、mro()与版本差异实战在Python 3里每个类都有__mro__属性存的是元组顺序就是属性查找顺序mro()方法返回一个列表内容一样。想看一个类的父类可以用__bases__但它只包含直接父类。实际调试时我更推荐打印__mro__因为它非常直观地告诉你解析路径会走哪些类。经典类和新式类最大的区别就是是否继承object。Python 2的经典类不继承objectMRO按照深度优先处理菱形问题依然存在Python 3里所有类都自动继承object所以都是新式类统一走C3。如果你在维护老项目看到class A:这种写法在Python 2里是经典类在Python 3里则自动是新式类行为完全不同。Python 2.2到2.3之间还存在一段过渡期的MRO算法它比DFS好一点但在某些复杂多重继承下会产生不一致2.3改用C3后这些历史问题才算彻底解决。现在讨论MRO基本只需要关心C3。4. super()与MRO的协作机制4.1 super的作用不是“调用父类方法”很多人的认知里super()就是找父类这个理解在单一继承下碰巧能用但在多重继承里会让人抓狂。super(D, self).who()的实际行为是先拿到self的真实类型找到它的MRO然后定位到D在这个MRO中的位置从D的下一个类开始查找who。也就是说super是顺着MRO往下走的“代理”不是直接跳到你想象中的父类。class A: def who(self): print(A) class B(A): def who(self): print(B) super().who() class C(A): def who(self): print(C) super().who() class D(B, C): def who(self): print(D) super().who() D().who()这里的执行结果很多人猜错输出是D、B、C、A而不是D、B、A。因为B里的super().who()顺着self的真实类型D的MRO走到B之后下一个是C于是C.who()被调用。这就是协作式多继承的关键super()永远以self的MRO为准而不是以当前类的父类为准。理解了这一点你才能真正看懂Mixins设计的精髓。4.2 协作式多继承Mixins的基石Mixins是Python多继承最优雅的应用方式它的前提条件就是所有参与类都愿意通过super()把调用链传递下去。如果中间某个类不用super()而是直接调用某个具体类链子就会断。最典型的就是__init__的调用链class Base: def __init__(self, **kwargs): self.name kwargs.pop(name, default) super().__init__(**kwargs) class LogMixin: def __init__(self, **kwargs): print(f初始化 {self.__class__.__name__}) super().__init__(**kwargs) class Service(LogMixin, Base): pass s Service(nametest)这里Service没有自己的__init__但MRO是Service → LogMixin → Base → object。调用Service(test)时object的__init__会被Base里的super()触达整个链路上的初始化逻辑全都执行了一遍。如果Base里不用super()而改成直接object.__init__LogMixin的初始化就被跳过或者会重复执行。传递**kwargs几乎是协作式初始化的标配因为每个类都可能只需要其中一部分参数但必须把剩余的都往下传。另一个需要注意的点是如果某个类不打算继承任何东西它的super().__init__最终会落到object.__init__。此时如果还有多余的关键字参数object.__init__会报错所以每个类的构造器都必须主动pop掉自己需要的参数确保剩下的参数不会卡死在链尾。4.3 常见的super误区与排查技巧先说两个最经典的坑。第一个是super()的调用时机Python 3里可以不传参数写成super()但它的底层依赖编译器帮你填上(__class__, self)如果你在方法外、或者装饰器场景下想用super()就没办法省略了。第二个是super(type, obj)里第二参数的类型必须和第一参数兼容更准确地说isinstance(obj, type)要为真或者type必须是obj的某个祖先反过来如果第二参数是个类则需要issubclass(第二参数, type)。写错的人不少最常见的就是在__new__里用super().__new__(cls)这种没问题但在一个类方法里用super(Child, child_instance)就可能出错。排查MRO相关问题时我最常用的手段是临时打印self.__class__.__mro__。比如你发现某个方法调用链不符合预期不要猜直接在入口打印MRO和当前类的__dict__一眼就能看出解析到哪里了。还有一个容易被忽略的辅助函数是inspect.getmro(类)它返回跟__mro__一样的结果但适合在不知道类对象还是实例对象时统一处理。5. 实践中的类属性与MRO避坑指南5.1 共享状态用类属性但可变对象要特别小心类属性的最大价值就是共享状态。经典场景包括全局配置、实例计数器、缓存池、注册表。比如你想统计一个类创建了多少个实例class User: count 0 def __init__(self): User.count 1这里必须写User.count 1如果写self.count 1效果是读取类属性count加1然后赋值到实例字典里类属性永远不变。这种细节在面试题里出现频率极高本质上还是第一节说的“读和写不对称”。缓存池的例子也同样类属性保存字典实例往里写键值对所有实例都能看到同一个缓存非常实用。但共享可变对象是一把双刃剑。如果你把列表、字典、集合用作类属性同时又有人对实例做原地修改影响范围很难控制。我的习惯是能定义为元组、字符串这类不可变对象的尽量用不可变类型必须共享可变对象时提供类方法或类级别的接口不要放任实例直接操作底层数据。5.2 类方法、静态方法和实例方法怎么选这个选择题很多初学者做不好。实例方法的第一个参数是self它需要实例上下文类方法的第一个参数是cls它可以操作类属性也能被实例调用静态方法既不需要实例也不需要类纯粹是组织在类命名空间里的工具函数。举个例子会更清楚class Database: default_conn localhost classmethod def get_conn(cls): return cls.default_conn staticmethod def validate_port(port): return 0 port 65535 def connect(self, port): if not self.validate_port(port): raise ValueError(端口不合法) print(f连接 {self.get_conn()}:{port})注意validate_port里不需要任何类或实例信息所以定义成静态方法get_conn要访问类属性所以用类方法connect需要实例自身的逻辑所以是实例方法。很多人喜欢把工具函数全塞成静态方法但如果你发现某个静态方法里总是用到cls.xxx那它就该是类方法。还有个实际经验当你写一个基类希望子类能覆盖某个属性并且该覆盖要影响后续逻辑时用类方法比用硬编码的类属性更可靠。因为cls会自动指向调用时的真实类子类覆盖类属性后类方法不需要重写。5.3 属性解析问题三步定位法遇到“属性值不对”或者“方法调错”的线上问题我有一套固定排查流程分享给你。第一步打印实例和类的字典确认属性到底存在哪里。vars(instance)看实例属性vars(Class)看类属性。这一步能快速区分“值是错的”还是“根本没这个属性”。第二步打印type(instance).__mro__确认类的继承顺序。如果属性值来自继承链中的某个类顺序错了你看到的就会是另一个类的属性。菱形继承、Mixins顺序不对这类问题在MRO上立马现形。第三步检查类属性是否是描述符。如果类属性是property、classmethod、staticmethod或自定义描述符那么实例赋值行为可能不会按普通属性逻辑执行。特别是数据描述符优先级高于实例字典你往实例上赋值根本不会生效。这个方法看似简单但我靠它解决了不少诡异的Bug。有一次线上数据显示异常查了半天最后发现是基类的一个类属性被某个子类实例原地修改了导致所有子类共享的缓存被污染。用第一步打印字典就定位到了问题根本不需要翻业务代码。5.4 常见问题速查表现象可能原因处理方式实例修改类属性值其他实例没变赋值操作在实例字典里新建了键产生了遮蔽明确用Class.attr赋值而不是self.attr 实例修改类列表其他实例跟着变原地修改了类属性指向的可变对象要么改用不可变默认值要么在__init__里创建实例副本两个基类都有同名方法但调用结果很“奇怪”MRO顺序导致选了“声明顺序靠前”的类打印__mro__确认顺序调整基类声明顺序或重新设计继承关系super()调用后链路上某些逻辑没执行某层没有调用super()调用链中断检查所有参与多继承的类是否都用了super()__init__传参莫名报错**kwargs没被链路上所有类正确消费和传递每个类先pop自己需要的参数再把剩余参数传给super()类属性定义了property实例却无法遮蔽它数据描述符优先级高于实例字典重新评估设计数据描述符本身就是有意强制约束老代码在Python 2和Python 3行为不同Python 2经典类用DFSPython 3统一用C3升级时重点检查多重继承的调用顺序mro()报TypeError: Cannot create a consistent MROC3合并时无法满足单调性约束调整基类顺序或改用组合代替多重继承这些场景不一定每天都能遇到但只要你写多继承或者维护老项目早晚会撞上其中几个。把这表格存下遇到问题先对号入座能省很多排查时间。最后再分享一个我个人很受用的经验。很多人学MRO时喜欢背算法但实际工作中真正需要你手算C3的机会少之又少更重要的是理解它的约束和意图。C3算法之所以被选中是因为它满足了三个朴素需求子类在父类之前多个基类保持声明顺序以及同一个类在MRO里不重复出现。只要你设计继承结构时始终问自己一句“这条链上每个类的方法会不会都被正确触发”大部分多继承问题都能在设计阶段就被消灭。真遇到解析顺序不符合预期的时候也别急着骂Python先打印__mro__看一遍多数时候你会发现是你把基类的顺序写反了。