Python OOP 体系深度解析

本文适合有 Java 背景、正在学习 Python 的开发者。用熟悉的术语类比，从 obj.attr 到底发生了什么，到 descriptor、MRO、metaclass 构成的属性查找引擎，系统性介绍 Python OOP 体系的底层运作机制。

写在前面

在学习 Python 的过程中，我发现 Python 的 OOP 与 Java 有着本质的不同——Java 开发者习惯了"OOP = 继承树 + 编译期方法绑定"，面对 Python 的 super() 行为、property 底层原理、metaclass 时往往感到困惑。你不需要写框架，但你在用框架——Django 的 Model、FastAPI 的 Depends、Pydantic 的 BaseModel，它们的内部到处是 descriptor、MRO 和 metaclass。不理解协议栈，你永远在猜框架为什么这么工作。

前提：本文假设你已读过《Python OOP 基础认知翻译》（系列第五篇），知道 Python 中 class 怎么写、self 为什么是显式的、__init__ 不是构造器、类属性在实例间共享等基础概念。如果你还没读过，建议先读那篇——本文是"为什么这么设计"，那篇是"怎么用"。

一句话总结：Python 的 OOP 不是继承树，而是一个运行时的属性查找协议栈——你不写框架，但你在用框架，不理解协议栈，你永远在猜框架为什么这么工作。

本文从 obj.attr 出发，自顶向下遍历协议栈的每一层，覆盖 8 个核心主题：

本文是《Python 内存管理深度解析》、《Python 并发深度解析》、《Python 类型系统深度解析》、《Python 导入系统深度解析》和《Python OOP 基础认知翻译》的姊妹篇。本文是系列第六篇，与类型系统篇形成"设计时双子星"：类型系统讲"数据长什么样"，OOP 体系讲"行为怎么组织"。

下面逐一展开。

一、obj.attr 到底发生了什么？

1.1 从 Java 的最简单操作说起

在 Java 中，obj.field 是简单直接的——编译期确定了字段在对象内存中的偏移量，运行时就是一次内存读取：

class Point {
int x;
int y;
}

Point p = new Point();
p.x = 10; // 编译期确定 x 在 Point 对象内的偏移量，运行时直接写入内存

在 Python 中，obj.attr 看起来一样，但背后是一次协议协商——沿着四层协议栈逐层查找，每一层都有机会拦截：

┌─────────────────────────────────────────────────────────────────────┐
│ Python 属性查找协议栈（obj.attr） │
│ │
│ obj.attr │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Layer 1: 数据描述符（data descriptor） │ │
│ │ 协议: __get__ + __set__/__delete__ │ │
│ │ 查找位置: type(obj).__dict__ 中（遍历 MRO 链） │ │
│ │ 优先级: 最高。如果找到数据描述符，直接返回，不查实例 __dict__ │ │
│ │ 类比: Java 中你无法拦截 obj.field，但 Python 的 descriptor 可以 │ │
│ └──────────────────────────────┬─────────────────────────────────┘ │
│ │ 未命中 │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Layer 2: 实例 __dict__ │ │
│ │ 协议: 普通字典查找 │ │
│ │ 查找位置: obj.__dict__ │ │
│ │ 优先级: 次高。实例自己的属性优先于类属性 │ │
│ │ 类比: Java 的 this.field（实例字段） │ │
│ └──────────────────────────────┬─────────────────────────────────┘ │
│ │ 未命中 │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Layer 3: MRO 链（沿 C3 线性化顺序搜索类字典） │ │
│ │ 协议: 在 type(obj).__mro__ 链上依次查找每个类的 __dict__ │ │
│ │ 特殊: 非数据描述符（仅有 __get__）在此触发 │ │
│ │ 优先级: 按 C3 线性化顺序 │ │
│ │ 类比: Java 的 vtable 方法分派，但 Python 是属性查找而非方法调用 │ │
│ └──────────────────────────────┬─────────────────────────────────┘ │
│ │ 未命中 │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Layer 4: __getattr__ 兜底 │ │
│ │ 协议: 自定义 fallback 逻辑 │ │
│ │ 触发条件: 前三层都找不到且类定义了 __getattr__ │ │
│ │ 优先级: 最低，前面都找不到才触发 │ │
│ │ 类比: Java 无直接类比（最接近的是动态代理 InvocationHandler） │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Meta-layer: metaclass 控制"类对象"的创建 │ │
│ │ 协议: type.__new__ 在类定义时被调用，决定类的属性字典 │ │
│ │ 影响: 决定了 Layer 2-3 中有什么可以被查找 │ │
│ │ 类比: Java 编译期注解处理器（但 Python 是运行时） │ │
│ └────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘

1.2 用代码验证协议栈

我们用一个综合示例来验证这四层协议栈的优先级：

class NonDataDescriptor:
"""非数据描述符：只有 __get__"""
def __get__(self, instance, owner):
return "from non-data descriptor"

class DataDescriptor:
"""数据描述符：有 __get__ + __set__"""
def __get__(self, instance, owner):
return "from data descriptor"
def __set__(self, instance, value):
pass # 有 __set__ 就是数据描述符

class MyClass:
data_desc = DataDescriptor() # 类属性：数据描述符
non_data_desc = NonDataDescriptor() # 类属性：非数据描述符

def __init__(self):
self.data_desc = "from instance __dict__" # ❌ 不会覆盖数据描述符！
self.non_data_desc = "from instance __dict__"

obj = MyClass()
print(obj.data_desc) # "from data descriptor" ← Layer 1 拦截了！
print(obj.non_data_desc) # "from instance __dict__" ← Layer 2 覆盖了 Layer 3
print(obj.__dict__) # {'non_data_desc': 'from instance __dict__'}
# 注意：data_desc 不在 __dict__ 中！

1.3 核心认知：每个 obj.attr 都是一次 lookup

Java 开发者习惯"字段访问 = 内存读取"。Python 的 obj.attr 是一次沿着协议栈的查找过程——每次属性访问都可能触发 descriptor 的 __get__、遍历 MRO 链、最终落到 __getattr__ 兜底。

这个差异意味着：

• 在 Java 中，obj.field 的性能是 O(1)（偏移量读取）
• 在 Python 中，obj.attr 的性能取决于查找路径的长度（但通常也有缓存优化）

对比 Java：Java 的字段访问是编译期确定的，JVM 直接通过偏移量读写内存。Python 的字段访问是运行时的协议协商——这让 Python 的 OOP 极其灵活，但也是性能敏感场景需要关注的点。

二、descriptor：属性访问的拦截器

2.1 数据描述符 vs 非数据描述符

descriptor 是 Python 属性查找协议栈的核心。任何定义了 __get__、__set__、__delete__ 中至少一个方法的对象，就是 descriptor。此外，__set_name__(self, owner, name) 在类创建时自动调用，让 descriptor 获知自己的属性名（详见第 5.5 节）。按方法组合分为两类：

┌──────────────────────────────────────────────────────────────────┐
│ descriptor 分类 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 数据描述符（data descriptor） │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 定义了 __get__ + __set__ 或 __delete__ │ │
│ │ 优先级最高，在 Layer 1 被触发 │ │
│ │ 即使实例 __dict__ 中有同名属性，也会被描述符拦截 │ │
│ │ 典型: property │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 非数据描述符（non-data descriptor） │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 只定义了 __get__ │ │
│ │ 在 Layer 3（MRO 链）被触发 │ │
│ │ 实例 __dict__ 中的同名属性会覆盖非数据描述符 │ │
│ │ 典型: function（普通方法）、classmethod、staticmethod │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────┘

# 数据描述符的完整协议
class DataDesc:
def __get__(self, instance, owner):
"""属性读取时调用"""
# instance: 实例对象（类级别访问时为 None）
# owner: 所属的类
if instance is None:
return self
return instance._value

def __set__(self, instance, value):
"""属性赋值时调用"""
instance._value = value

def __delete__(self, instance):
"""del obj.attr 时调用"""
del instance._value

class MyClass:
attr = DataDesc() # 类属性，但是一个 descriptor

2.2 property 就是 descriptor

property 是 Python 内置的最常用的数据描述符。它本质上是一个 C 实现的 descriptor：

class Celsius:
def __init__(self, temperature=0):
self._temperature = temperature

@property
def temperature(self): # temperature 是一个 descriptor 对象
return self._temperature

@temperature.setter
def temperature_setter(self, value):
if value < –273.15:
raise ValueError("Temperature below absolute zero")
self._temperature = value

# 等价于手动实现 property 的 descriptor 版本
class PropertyDescriptor:
def __init__(self, fget=None, fset=None, fdel=None):
self.fget = fget
self.fset = fset
self.fdel = fdel

def __get__(self, instance, owner):
if instance is None:
return self
return self.fget(instance)

def __set__(self, instance, value):
if self.fset is None:
raise AttributeError("can't set attribute")
self.fset(instance, value)

def __delete__(self, instance):
if self.fdel is None:
raise AttributeError("can't delete attribute")
self.fdel(instance)

当你写 @property 时，Python 实际上创建了一个 descriptor 对象。obj.attr 的读取会触发 descriptor 的 __get__，赋值会触发 __set__。

2.3 classmethod / staticmethod 也是 descriptor

classmethod 和 staticmethod 同样是非数据描述符——它们只定义了 __get__：

class MyClass:
@classmethod
def from_string(cls, s):
return cls(s)

@staticmethod
def helper(x):
return x * 2

# classmethod 的 descriptor 本质：
# MyClass.from_string → 调用 descriptor.__get__(None, MyClass) → 返回绑定到 MyClass 的方法
# obj.from_string() → 调用 descriptor.__get__(obj, MyClass) → 返回绑定到 type(obj) 的方法

# 普通方法的 descriptor 本质：
# obj.method() → 函数对象.__get__(obj, MyClass) → 返回绑定方法（bound method）
# MyClass.method() → 函数对象.__get__(None, MyClass) → 返回原始函数

# 这就是为什么 obj.method() 和 MyClass.method(obj) 等价
# 因为函数对象也是 descriptor！

关键认知：Python 的普通函数也是 descriptor。当你通过实例访问方法时，function.__get__ 返回一个绑定了实例的 bound method 对象。这就是 self 参数的来由——不是语言特性，是 descriptor 协议的效果。

def greet(self, name):
return f"Hello {name}, I'm {self.name}"

class Person:
def __init__(self, name):
self.name = name

# 手动绑定：利用 descriptor 协议
Person.greet = greet # 将函数作为类属性

p = Person("Alice")
print(p.greet("Bob")) # Hello Bob, I'm Alice
# 因为 greet 是 descriptor，p.greet 触发 __get__ → 返回绑定方法

2.4 Java 对比

核心差异：Java 的 getter/setter 是命名约定（叫 getX 就是 getter），Python 的 descriptor 是协议机制（有 __get__ 就是 descriptor）。后者更底层、更灵活，但也更需要理解协议栈。

2.5 descriptor 的实例共享陷阱

descriptor 定义在类级别，所有实例共享同一个 descriptor 对象。如果你在 descriptor 中存储实例级别的状态，需要自己管理：

# ❌ 错误：所有实例共享同一个 descriptor 的 _value
class BadDescriptor:
def __get__(self, instance, owner):
return instance._value # 还是会访问到实例的 __dict__
def __set__(self, instance, value):
instance._value = value

# ✅ 正确：用实例的 __dict__ 或弱引用字典存储每个实例的状态
from weakref import WeakKeyDictionary

class GoodDescriptor:
def __init__(self):
self._values = WeakKeyDictionary() # 每个实例独立存储

def __get__(self, instance, owner):
if instance is None:
return self
return self._values.get(instance)

def __set__(self, instance, value):
self._values[instance] = value

这也是为什么 property 内部使用 instance._value 而非 self._value——self 是 descriptor 对象（类级别共享），instance 才是被访问的实例。

2.6 __slots__：关闭 __dict__ 的协议开关

__slots__ 从根本上改变了协议栈中 Layer 1 和 Layer 2 的行为：

class Point:
__slots__ = ('x', 'y') # 关闭 __dict__，x 和 y 在类级别变成 descriptor

def __init__(self, x, y):
self.x = x # 通过 descriptor 协议写入，不是 __dict__
self.y = y

p = Point(1, 2)
print(p.x, p.y) # 1 2
# p.z = 3 # AttributeError: 'Point' object has no attribute 'z'
# p.__dict__ # AttributeError: 'Point' object has no attribute '__dict__'

关键认知：

• 有 __slots__ 的类实例没有 __dict__，不能动态添加属性（除非 __slots__ 包含 __dict__）
• __slots__ 中的每个属性名在类级别创建了一个 descriptor，属性访问通过 descriptor 协议而非 __dict__ 查找
• 这是 Python 中"最像 Java 固定字段布局"的机制——但实现方式完全不同：Java 是编译期内存偏移量，Python 是运行时 descriptor 协议

对比 Java：Java 的字段在编译期确定内存布局，__slots__ 在 Python 中实现了类似效果——禁止动态属性、节省内存。但 __slots__ 在继承时有复杂规则：子类不会自动继承父类的 __slots__，需要显式声明。

三、MRO 与多重继承

3.1 为什么需要 MRO？

Python 支持多重继承，这意味着一个类可以从多个父类继承。这就产生了一个问题：如果多个父类有同名方法，该调用哪个？

A
/ \\
B C
\\ /
D

class D(B, C): # 继承 B 和 C，B 和 C 都继承 A
pass

MRO（Method Resolution Order，方法解析顺序）用一个线性序列解决了这个问题。Python 使用 C3 线性化算法，它遵循两个核心原则：

• 单调性：如果一个类在 MRO 中排在另一个类前面，那么在任何子类中这个顺序不变
• 局部优先：子类在父类之前，书写顺序中左边的类在右边的类之前

class A:
def who(self):
return "A"

class B(A):
def who(self):
return "B"

class C(A):
def who(self):
return "C"

class D(B, C):
pass

print(D.__mro__)
# (<class 'D'>, <class 'B'>, <class 'C'>, <class 'A'>, <class 'object'>)

print(D().who()) # "B" — 因为 B 在 MRO 中排在 C 前面

3.2 super() 的真实语义

这是 Java 开发者最容易误解的地方。Java 的 super 是编译期确定的——super.method() 总是调用直接父类的方法。Python 的 super() 是运行时沿 MRO 链查找——它找的是 MRO 链中当前类之后的第一个实现了该方法的类，不一定是直接父类。

┌─────────────────────────────────────────────────────────────────┐
│ super() 的语义：Java vs Python │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Java super: │
│ class B extends A { void m() { super.m(); } } │
│ → super.m() 编译期确定 = A.m()，永远是直接父类 │
│ │
│ Python super(): │
│ class B(A): │
│ def m(self): super().m() │
│ → super() 返回一个代理对象，沿 MRO 链在 B 之后找下一个有 m() 的类 │
│ → 在 diamond 继承中，B 之后的下一个可能是 C 而不是 A │
│ │
└─────────────────────────────────────────────────────────────────┘

class A:
def process(self):
print("A.process")

class B(A):
def process(self):
print("B.process start")
super().process() # 在 MRO 链中 B 之后找下一个有 process 的类
print("B.process end")

class C(A):
def process(self):
print("C.process start")
super().process()
print("C.process end")

class D(B, C):
def process(self):
print("D.process start")
super().process()
print("D.process end")

# D 的 MRO: D → B → C → A → object
D().process()
# 输出:
# D.process start
# B.process start
# C.process start ← B 的 super() 调到了 C！不是 A！
# A.process
# C.process end
# B.process end
# D.process end

这就是 super() 的"协作式多继承"模式——每个类只负责自己的逻辑，然后通过 super() 把控制权交给 MRO 链上的下一个类。这要求所有参与协作的类都调用 super()，否则链条会断。

对比 Java：Java 没有多继承，super 永远是直接父类。Python 的 super() 在 diamond 继承中可能跳到"兄弟"类——这是设计，不是 bug，但需要理解 MRO 才能正确使用。

3.3 C3 线性化的核心原则

C3 算法保证 MRO 同时满足：

如果这三条不能同时满足，Python 会直接拒绝创建类：

# 违反 C3 的继承结构
class X: pass
class Y(X): pass
class Z(X, Y): pass # TypeError: Cannot create a consistent MRO
# 因为 X 的 MRO 中 X 在 Y 前，但 Z 声明的父类顺序要求 Y 在 X 前，无法构成一致的 MRO

3.4 检查 MRO 的方法

# 方法 1：__mro__ 属性
print(D.__mro__)

# 方法 2：mro() 方法
print(D.mro())

# 方法 3：inspect 模块
import inspect
print(inspect.getmro(D))

本节核心要点：MRO 不是"继承树的遍历顺序"，而是 C3 算法计算出的线性序列。super() 不是"调用父类"，而是"沿 MRO 链找下一个"。理解这两个概念，diamond 继承中 super() 的"跳跃"行为就不再神秘。

四、__getattr__ 与 __getattribute__

4.1 入口 vs fallback

回顾协议栈，这两个方法在查找流程中的位置不同：

obj.attr
│
▼
┌──────────────────────┐
│ __getattribute__() │ ← 始终调用，是属性查找的入口
│ 执行 Layer 1→2→3 的查找 │
│ │
│ 找到了 → 返回结果 │
│ 找不到 → 抛出 │
│ AttributeError │
└──────────┬───────────┘
│ AttributeError
▼
┌──────────────────────┐
│ __getattr__() │ ← 仅在 __getattribute__ 找不到时触发
│ 自定义 fallback 逻辑 │ 是"兜底"，不是"入口"
└──────────────────────┘

class MyClass:
def __init__(self):
self.existing = 42

def __getattribute__(self, name):
print(f"__getattribute__ called for '{name}'")
return super().__getattribute__(name) # 必须调用 super！

def __getattr__(self, name):
print(f"__getattr__ called for '{name}'")
return f"dynamic_{name}"

obj = MyClass()
print(obj.existing) # __getattribute__ → 找到 → 返回 42
print(obj.missing) # __getattribute__ → 找不到 → __getattr__ → 返回 "dynamic_missing"

4.2 __getattr__ 的典型场景

场景 1：代理模式

class Proxy:
def __init__(self, target):
self._target = target

def __getattr__(self, name):
"""将未定义的属性访问转发给目标对象"""
return getattr(self._target, name)

# 任何对 Proxy 实例的未定义属性访问，都转发给 _target
proxy = Proxy([1, 2, 3])
print(proxy.append) # 转发给 list.append
print(proxy.pop()) # 转发给 list.pop，输出 3

场景 2：惰性属性

class LazyConfig:
def __init__(self):
self._loaded = {}

def __getattr__(self, name):
"""从数据库加载配置，只在第一次访问时加载"""
if name.startswith('_'):
raise AttributeError(name)
value = self._load_from_db(name) # 模拟数据库查询
self._loaded[name] = value
return value

def _load_from_db(self, name):
print(f"Loading {name} from database…")
return f"db_value_for_{name}"

场景 3：动态 API

class DynamicAPI:
def __getattr__(self, name):
if name.startswith('find_by_'):
field = name[len('find_by_'):]
return lambda value: f"SELECT * WHERE {field} = {value}"
raise AttributeError(f"No such method: {name}")

api = DynamicAPI()
print(api.find_by_name("Alice")) # SELECT * WHERE name = Alice
print(api.find_by_age(30)) # SELECT * WHERE age = 30

4.3 __getattribute__ 的典型场景

__getattribute__ 用于全局拦截所有属性访问，但需要极其小心：

class LoggedAccess:
def __init__(self):
self._data = {}

def __getattribute__(self, name):
# 不能直接访问 self._data！会触发无限递归
# 必须通过 super().__getattribute__ 或 object.__getattribute__
if name.startswith('_'):
return super().__getattribute__(name)
print(f"Accessing: {name}")
return super().__getattribute__(name)

4.4 __getattribute__ 的无限递归陷阱

这是最致命的陷阱：

# ❌ 无限递归！
class Bad:
def __getattribute__(self, name):
return self.__dict__[name] # self.__dict__ 又会触发 __getattribute__！

# ✅ 正确做法
class Good:
def __getattribute__(self, name):
# 必须通过 super() 绕过自己的 __getattribute__
return super().__getattribute__(name)

对比 Java：__getattr__ 最接近 Java 的动态代理（InvocationHandler.invoke()），但 Python 是语言级别的原生支持，不需要创建代理对象。__getattribute__ 无直接 Java 类比——它是属性访问的全局拦截器，类似 AOP 的 around advice，但作用于对象而非方法。

4.5 三者选型速查

4.6 __setattr__ 与 __delattr__：协议栈的另一半

第 4 节讲了 get 侧，但 obj.attr = value 和 del obj.attr 也有对应的协议入口：

obj.attr = value
│
▼
__setattr__('attr', value) ← 始终调用，是赋值的入口
│
▼
descriptor.__set__? → 有则调用，无则下一步
│
▼
obj.__dict__['attr'] = value

class Guarded:
def __setattr__(self, name, value):
if name == 'secret':
raise AttributeError("Cannot set 'secret'")
super().__setattr__(name, value) # 必须用 super() 绕过！

def __delattr__(self, name):
print(f"Deleting {name}")
super().__delattr__(name)

g = Guarded()
g.x = 10 # 正常
# g.secret = 42 # AttributeError: Cannot set 'secret'
del g.x # "Deleting x"

关键陷阱：__setattr__ 中写 self.xxx = value 会导致无限递归，与 __getattribute__ 的陷阱完全对称——必须用 super().__setattr__() 绕过。

对比 Java：Java 没有 __setattr__ 的直接类比——字段赋值是直接内存写入，无法拦截。Python 的 __setattr__ 让你可以在赋值时做校验、日志、转换，这是 AOP 做不到的细粒度控制。

五、metaclass：类创建的钩子

5.1 类也是对象

在 Python 中，类本身也是对象——它是 type 的实例：

class MyClass:
pass

print(type(MyClass)) # <class 'type'> — 类对象是 type 的实例
print(type(42)) # <class 'int'> — 整数对象是 int 的实例

# 统一模型：一切都是对象，一切对象都有类型
# 实例的类型是类，类的类型是 metaclass（默认是 type）

┌─────────────────────────────────────────────────────────────────┐
│ Python 对象体系 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 实例 ── isinstance ──▶ 类 ── isinstance ──▶ metaclass (type) │
│ obj ──── type ────▶ MyClass ──── type ────▶ type │
│ │
│ type 是 Python 对象体系的"根"——type 的 type 是它自己 │
│ print(type(type)) # <class 'type'> │
│ │
└─────────────────────────────────────────────────────────────────┘

5.2 type 的两种用法

type 有两种完全不同的用法：

# 用法 1：获取对象的类型（日常使用）
print(type(42)) # <class 'int'>

# 用法 2：动态创建类（metaclass 的核心）
# type(name, bases, dict) → 创建一个新类
MyClass = type('MyClass', (object,), {'x': 10, 'hello': lambda self: "world"})

obj = MyClass()
print(obj.x) # 10
print(obj.hello()) # world

class 语句本质上是 type.__new__ 的语法糖：

# class MyClass(Base):
# x = 10
# def hello(self): return "world"

# 等价于：
MyClass = type('MyClass', (Base,), {'x': 10, 'hello': lambda self: "world"})

5.3 metaclass 的工作原理

metaclass 是 type 的子类，它拦截类的创建过程：

class MyMeta(type):
def __new__(mcs, name, bases, namespace):
# mcs: metaclass 本身（这里是 MyMeta）
# name: 类名（字符串）
# bases: 父类元组
# namespace: 类的属性字典（在 __new__ 阶段就是一个 dict）
print(f"Creating class: {name}")
print(f" Bases: {bases}")
print(f" Attributes: {[k for k in namespace if not k.startswith('_')]}")

# 可以在这里修改 namespace
namespace['created_by'] = 'MyMeta'
return super().__new__(mcs, name, bases, namespace)

class MyClass(metaclass=MyMeta):
x = 10
def hello(self):
return "world"

# 输出:
# Creating class: MyClass
# Bases: (<class 'object'>,)
# Attributes: ['x', 'hello']

print(MyClass.created_by) # "MyMeta" — metaclass 注入的属性

5.4 metaclass 的应用场景

场景 1：ORM 字段注册（Django 风格）

class Field:
def __init__(self, field_type):
self.field_type = field_type

class ModelMeta(type):
def __new__(mcs, name, bases, namespace):
fields = {}
for key, value in namespace.items():
if isinstance(value, Field):
fields[key] = value
namespace['_fields'] = fields
return super().__new__(mcs, name, bases, namespace)

class Model(metaclass=ModelMeta):
pass

class User(Model):
name = Field('varchar')
age = Field('integer')

print(User._fields) # {'name': <Field>, 'age': <Field>}

场景 2：单例模式

class SingletonMeta(type):
_instances = {}

def __call__(cls, *args, **kwargs):
# cls() 触发 __call__，在实例创建之前拦截
if cls not in cls._instances:
cls._instances[cls] = super().__call__(*args, **kwargs)
return cls._instances[cls]

class Database(metaclass=SingletonMeta):
def __init__(self):
print("Initializing database connection…")

db1 = Database() # Initializing database connection…
db2 = Database() # (无输出，返回缓存的实例)
print(db1 is db2) # True

5.5 __init_subclass__：大多数场景不需要 metaclass

__init_subclass__ 是 Python 3.6 引入的，在子类被定义时自动调用。它比 metaclass 轻量得多：

class PluginBase:
_registry = {}

def __init_subclass__(cls, **kwargs):
"""子类定义时自动注册"""
super().__init_subclass__(**kwargs)
PluginBase._registry[cls.__name__] = cls

class CSVPlugin(PluginBase):
pass

class JSONPlugin(PluginBase):
pass

print(PluginBase._registry) # {'CSVPlugin': CSVPlugin, 'JSONPlugin': JSONPlugin}

__set_name__ 配合 descriptor 使用，在类创建时自动获知属性名：

class ValidatedField:
def __set_name__(self, owner, name):
"""类创建时自动调用，告诉 descriptor 它在类中的属性名"""
self.name = name
self.private_name = f'_{name}'

def __get__(self, instance, owner):
if instance is None:
return self
return getattr(instance, self.private_name, None)

def __set__(self, instance, value):
setattr(instance, self.private_name, value)

class User:
name = ValidatedField() # 不需要手动传属性名了！
age = ValidatedField()

选型指南：

5.6 metaclass 冲突

当两个父类使用不同的 metaclass 时，Python 无法确定子类该用哪个 metaclass：

class MetaA(type): pass
class MetaB(type): pass

class A(metaclass=MetaA): pass
class B(metaclass=MetaB): pass

# ❌ TypeError: metaclass conflict
# class C(A, B): pass

# ✅ 解决方案：确保所有 metaclass 有共同的继承链
class MetaAB(MetaA, MetaB): pass

class C(A, B, metaclass=MetaAB): pass

对比 Java：metaclass 最接近 Java 的编译期注解处理器（APT），但有两个关键差异：① Python 的 metaclass 是运行时的（类定义时立即执行），Java 的注解处理器是编译期的；② metaclass 可以修改类的行为（注入方法、修改属性），而注解处理器主要生成新代码。__init_subclass__ 更像 Java 的注解——标记一个类，让它自动注册，但不需要修改类的创建过程。

5.7 __prepare__：控制类体的命名空间

metaclass 创建流程有三步：__prepare__ → __new__ → __init__。__prepare__ 在类体执行之前被调用，返回的映射对象作为类体的命名空间：

from collections import OrderedDict

class OrderedMeta(type):
@classmethod
def __prepare__(mcs, name, bases):
# 返回 OrderedDict，类体中的属性按定义顺序保留
return OrderedDict()

class MyClass(metaclass=OrderedMeta):
z = 3
a = 1
m = 2

# __dict__ 中的属性按定义顺序排列
print(list(MyClass.__dict__.keys())[:5]) # …, 'z', 'a', 'm', …

关键认知：

• __prepare__ 是 enum.Enum 和 typing.NamedTuple 的底层机制——Enum 用自定义命名空间防止重复值
• __prepare__ 返回的命名空间是 __init_subclass__ 的 **kwargs 能传递的前提
• 这是 metaclass 三件套中最少被重写的一个——日常开发几乎不需要

六、选型决策框架

6.1 属性访问控制：选什么？

我需要拦截属性访问
│
├── 只拦截特定属性的 get/set
│ └──▶ @property（最简单，语法糖）
│
├── 需要通用校验逻辑，要在多个类中复用
│ └──▶ descriptor（定义 __get__/__set__/__delete__）
│
├── 未定义的属性要动态生成
│ └──▶ __getattr__（只在找不到时触发）
│
├── 全局拦截所有属性访问（日志、权限控制）
│ └──▶ __getattribute__（最强大，也最危险）
│
└── 只是给属性加个默认值或类型标注
└──▶ 普通类属性 + type hints（不需要拦截）

6.2 类创建时自动化：选什么？

我需要在类定义时自动做某事
│
├── 子类定义时自动注册（插件系统）
│ └──▶ __init_subclass__（轻量，推荐）
│
├── descriptor 需要自动获知属性名
│ └──▶ __set_name__（Python 3.6+）
│
├── 需要修改类的属性字典（注入方法、移除属性）
│ └──▶ metaclass.__new__（重武器）
│
├── 需要拦截实例创建（单例、对象池）
│ └──▶ metaclass.__call__（控制 cls() 的返回值）
│
└── 只是标记一个类，不需要修改
└──▶ 装饰器 @register（比 metaclass 简单）

6.3 完整决策表

注：Protocol 是 Python 3.8+ 的 typing.Protocol，类似 Java 的 interface——但不需要显式 implements。只要一个类有 protocol 要求的方法，类型检查器就认为它满足该 protocol（鸭子类型的静态版本）。

七、常见陷阱

7.1 descriptor 在实例间共享

descriptor 定义在类级别，所有实例共享同一个 descriptor 对象。如果你在 __set__ 中写 self.value = value（self 是 descriptor 自身），所有实例的取值都会被互相覆盖。正确做法是用 instance.__dict__ 或 WeakKeyDictionary 存储每个实例的独立状态——详见第 2.5 节。

7.2 super() 在 diamond 继承中的"跳跃"

super() 沿 MRO 链查找，不是"调用父类"。在 diamond 继承中，B 的 super() 可能跳到 C 而不是 A。这要求所有参与协作的类都调用 super()，否则链条会断。详见第 3.2 节。

补充：__mro__ 是只读属性，不能赋值修改。查看 MRO 使用 ClassName.__mro__ 或 ClassName.mro()。

7.3 __getattribute__ 无限递归

# ❌ 无限递归：self.name 触发 __getattribute__ → 又触发 __getattribute__ → …
class Bad:
def __init__(self, name):
self.name = name # 触发 __getattribute__

def __getattribute__(self, name):
return self.name # 又触发 __getattribute__！

# ✅ 正确：必须通过 super() 绕过
class Good:
def __init__(self, name):
super().__setattr__('name', name) # 绕过 __setattr__（如果有的话）

def __getattribute__(self, name):
if name == 'secret':
raise AttributeError("Access denied")
return super().__getattribute__(name) # 使用 super() 执行默认查找

黄金法则：在 __getattribute__ 中，任何对 self.xxx 的访问都必须通过 super().__getattribute__('xxx')。

7.4 metaclass 冲突

class MetaA(type): pass
class MetaB(type): pass

class A(metaclass=MetaA): pass
class B(metaclass=MetaB): pass

# ❌ 直接多继承 → TypeError
# class C(A, B): pass

# ✅ 方案 1：创建统一的 metaclass
class UnifiedMeta(MetaA, MetaB): pass
class C(A, B, metaclass=UnifiedMeta): pass

# ✅ 方案 2：如果只是简单的类注册，改用 __init_subclass__
class Registrable:
_registry = {}
def __init_subclass__(cls, **kwargs):
super().__init_subclass__(**kwargs)
Registrable._registry[cls.__name__] = cls

7.5 __del__ 的不可靠性

__del__ 是 Python 的"析构器"，但与 Java 的 finalize() 一样不可靠，不应依赖它做资源清理：

import weakref

class Resource:
def __init__(self, name):
self.name = name

def __del__(self):
print(f"Cleaning up {self.name}")

# 陷阱 1：循环引用阻止 __del__ 调用
a = Resource("A")
b = Resource("B")
a.other = b
b.other = a # 循环引用！GC 不会立即调用 __del__
del a, b # 可能不会打印 "Cleaning up…"

# 陷阱 2：__del__ 中访问全局变量可能已失效
import some_module
class Bad:
def __del__(self):
some_module.do_something() # 解释器关闭时 some_module 可能已被清理

最佳实践：用 with 语句（__enter__/__exit__）或 weakref.finalize 替代 __del__ 做资源清理。__del__ 唯一的合理用途是作为"最后的安全网"打印警告。

八、与 Java 全面对比

8.1 核心差异

8.2 根因分析

Java 和 Python 的 OOP 模型差异，根源在于两个语言的核心假设不同：

┌─────────────────────────────────────────────────────────────────────┐
│ Java OOP 体系 Python OOP 体系 │
│ ┌──────────────────────────┐ ┌──────────────────────────────┐ │
│ │ 核心假设：编译期确定 │ │ 核心假设：运行时可用 │ │
│ │ │ │ │ │
│ │ 继承树 │ │ 属性查找协议栈 │ │
│ │ │ │ │ │
│ │ Object │ │ obj.attr │ │
│ │ │ │ │ │ │ │
│ │ ┌──┴──┐ │ │ ▼ │ │
│ │ Animal Serializable │ │ data descriptor (Layer 1) │ │
│ │ │ │ │ │ │ │
│ │ ┌─┴─┐ │ │ ▼ │ │
│ │ Dog Cat │ │ instance __dict__ (Layer 2) │ │
│ │ │ │ │ │ │
│ │ 方法调用 = vtable 查找 │ │ ▼ │ │
│ │ 字段访问 = 内存偏移量 │ │ MRO 链 (Layer 3) │ │
│ │ 安全 = 编译期检查 │ │ │ │ │
│ │ 扩展 = 继承 + 接口 │ │ ▼ │ │
│ └──────────────────────────┘ │ __getattr__ (Layer 4) │ │
│ │ │ │
│ │ metaclass (Meta-layer) │ │
│ │ ───────────────────────── │ │
│ │ 方法调用 = MRO 链查找 │ │
│ │ 属性访问 = 协议栈逐层匹配 │ │
│ │ 安全 = 运行时校验 │ │
│ │ 扩展 = 协议 + duck typing │ │
│ └──────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘

一句话总结这个差异：Java OOP 是"编译期确定的类型层次"——你在写代码时，继承关系就固化了，方法调用路径在编译期就确定了。Python OOP 是"运行时协商的属性查找协议栈"——obj.attr 的每一次访问都是一次协议协商，你可以在运行时动态改变查找路径、拦截属性访问、甚至修改类的创建过程。

写在最后

Python 的 OOP 之所以让 Java 开发者困惑，根源在于一个认知差异：Java 的 OOP 是"编译期确定的类型层次"，Python 的 OOP 是"运行时协商的属性查找协议栈"。

为什么 Python OOP 比 Java 更难学？

Java 开发者只需要掌握一套 OOP 心智模型：单继承 → 多接口 → 方法重写 → super 调用父类。学习路径是线性的——class → extends → implements → @Override → 搞定。

Python 开发者需要理解协议栈的每一层：obj.attr 不是内存读取，而是 descriptor → __dict__ → MRO → __getattr__ 的协议协商；super() 不是调用父类，而是沿 MRO 链查找；@property 不是语法糖，而是 descriptor 协议；metaclass 不是"高级特性"，而是类创建过程的钩子。

Java 学习路径（线性）： Python 学习路径（分叉）：
┌─ descriptor 协议栈？property 底层是什么？
class → extends → implements → super → 搞定 │
────────────────────────────────────▶ class ──┼─ MRO？super() 为什么跳到了兄弟类？
一步到位，概念简单 │
├─ __getattr__ vs __getattribute__？
│
└─ metaclass？__init_subclass__？
────────────────────────────────────▶
每一层都是新的概念体系

更关键的是"必要性"的差异——Java 开发者不需要理解 vtable 就能写好 Java，但 Python 开发者不理解协议栈，就永远在猜框架为什么这么工作。Django 的 Model 字段收集、FastAPI 的 Depends 依赖注入、Pydantic 的 BaseModel 校验——这些框架的"魔法"背后都是 descriptor、MRO 和 metaclass。

回到协议栈

┌─────────────────────────────────────────────────────────────────┐
│ │
│ 你不写框架，但你在用框架。 │
│ │
│ Django 的 Model 字段收集 → metaclass 控制类创建 │
│ FastAPI 的 Depends 注入 → descriptor 拦截属性访问 │
│ Pydantic 的 BaseModel 校验 → `__init_subclass__` + descriptor │
│ SQLAlchemy 的惰性查询 → descriptor 实现惰性加载 │
│ │
│ 理解协议栈之前：这些是"魔法" │
│ 理解协议栈之后：这些是"协议"——每条规则都有迹可循 │
│ │
└─────────────────────────────────────────────────────────────────┘

记住一句话：Python 的 OOP 不是继承树，而是一个运行时的属性查找协议栈。obj.attr 不是一次内存读取，而是一次沿着 descriptor → MRO → __getattr__ 的协议协商。理解这一点，你就从"框架使用者"变成了"框架理解者"。

本文是"Python 深度解析"系列的第六篇，完成了第二层"设计范式"之 OOP 篇。下一篇将进入"装饰器与元编程"——装饰器是 Python 的 AOP，比 Spring AOP 更底层、更灵活。敬请期待。

系列文章：

• Python 内存管理深度解析
• Python 并发深度解析
• Python 类型系统深度解析
• Python 导入系统深度解析