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 个核心主题：

1. obj.attr 到底发生了什么？——属性查找协议栈全景
2. descriptor：属性访问的拦截器——property/classmethod/staticmethod 都是它
3. MRO 与多重继承——C3 线性化 + super() 的真实语义
4. __getattr__ 与 __getattribute__——默认查找 vs 自定义 fallback
5. metaclass：类创建的钩子——控制类的属性字典
6. 选型决策框架——什么时候用 descriptor？什么时候用 metaclass？
7. 常见陷阱——每种机制的坑点汇集
8. 与 Java 全面对比——继承树 vs 协议栈

本文是《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	Python
属性访问控制	getter/setter 是语法约定（getX()/setX()）	descriptor 是运行时协议（__get__/__set__）
方法绑定	编译期确定，this 是隐式参数	运行时通过 descriptor 协议绑定，self 是 descriptor 的产物
静态方法	static 关键字	@staticmethod 装饰器 = 非数据描述符
类方法	无直接类比	@classmethod 装饰器 = 非数据描述符
拦截字段访问	不可能（除非用 AspectJ 字节码织入）	原生支持，descriptor 直接拦截

核心差异：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 同时满足：

1. 子类先于父类：D 的 MRO 中 D 在最前面，object 在最后面
2. 声明顺序：D(B, C) 中 B 在 C 前面
3. 父类的 MRO 顺序保持：B 的 MRO 在 D 的 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 三者选型速查

需求	用什么	原因
仅拦截特定属性的 get/set	property	最简单，语法糖
需要通用属性校验/转换	descriptor	可复用，支持 __set__/__delete__
未定义属性动态生成	__getattr__	只在找不到时触发，不干扰已有属性
全局拦截所有属性访问	__getattribute__	最强大，但也是最容易出错的

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()

选型指南：

需求	用什么	理由
子类定义时自动注册	__init_subclass__	比 metaclass 轻量，不需要修改类创建流程
descriptor 需要知道属性名	__set_name__	避免手动传参
需要修改类的属性字典	metaclass	__init_subclass__ 在类已创建后调用，无法修改属性
需要拦截实例创建	metaclass __call__	控制 cls() 的返回值

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 完整决策表

场景	推荐方案	理由
属性的 get/set 校验	@property	简单，Pythonic，IDE 友好
通用校验逻辑复用	descriptor	可定义一次，多处使用
惰性加载属性	__getattr__	只在首次访问时计算
代理/转发模式	__getattr__	将未定义访问转发到目标对象
全局访问日志	__getattribute__	拦截一切，但需极致小心
插件自动注册	__init_subclass__	比 metaclass 简单 10 倍
ORM 字段收集	metaclass	需要在类创建时修改属性字典
单例模式	metaclass __call__	在实例创建前拦截
接口强制检查	ABC + @abstractmethod	标准库，运行时检查
能力声明	Protocol	结构化子类型，无需继承

注：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 核心差异

维度	Java	Python
继承模型	单继承 + 多接口	多重继承 + MRO
方法绑定	编译期确定（vtable）	运行时沿 MRO 链查找
属性访问	直接内存偏移量读取	协议栈逐层查找
getter/setter	语法约定（getX()/setX()）	descriptor 协议（__get__/__set__）
静态方法	static 关键字	@staticmethod（非数据描述符）
类方法	无直接类比	@classmethod（非数据描述符）
方法绑定	this 是隐式参数	self 是 descriptor 协议的产物
类创建钩子	注解处理器（编译期）	metaclass（运行时）
轻量注册	注解 + 反射	__init_subclass__
动态代理	InvocationHandler（创建代理对象）	__getattr__（在对象上直接实现）
属性访问拦截	不可能（AspectJ 字节码织入）	__getattribute__（原生支持）

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 导入系统深度解析