Python对象模型自举结构：type与object的循环关系深度拆解

在Python社区待久了你就会发现一个很有意思的现象：很多写了三五年业务代码的人，装饰器、上下文管理器、生成器都用得很溜，但被问到“type和object到底什么关系”这种问题时，常常会愣住。

我最早也被这个问题卡过。那会儿刚把Python当脚本语言用，觉得“类”就是用来创建对象的模板，直到某天读到一句话——Python里类也是对象。这个看似绕口的表述，背后藏着一套非常漂亮的、自我构建的对象模型。用编译原理里的话说，这叫“自举”：用Python自己的对象规则，来描述对象规则本身。

认真梳理完这块内容之后，我的感受是：这不仅仅是理论炫技。它决定了你对元类、描述符、__init_subclass__、动态创建类这些高级特性的理解深度，也直接影响你在写框架、调库、以及排查一些诡异报错时的底气。这篇就从一个研究项目的角度，把我拆解“Python对象模型自举结构”的完整过程写下来。不管你是刚装好Python准备入门的初学者，还是写了几年代码的进阶选手，这都值得花半小时读透。

1. 先搞清楚“一切皆对象”到底意味着什么

1.1 用 dir 和 type 撕开对象的表皮

我常说，想理解Python的对象模型，不要去看八股文，直接开一个交互式解释器，把内置类型一个个“盘”一遍。

python复制>>> type(1)
<class 'int'>
>>> type([])
<class 'list'>
>>> type(type(1))
<class 'type'>
>>> type(int)
<class 'type'>

前两行好理解：整数1是int类的实例，空列表是list类的实例。关键在于后面两行：int这个类本身，居然也有类型，它的类型是type。也就是说，Python中的类不仅仅是“创建实例的模板”，它自己也作为对象存在，可以被传递、被赋值、被动态创建。

再往下看：

python复制>>> int.__class__
<class 'type'>
>>> type.__class__
<class 'type'>
>>> object.__class__
<class 'type'>

连type自己、连所有类的基类object，它们各自的__class__也还是type。你可以把__class__理解为“这个对象是谁造出来的”。实例是由类造的，而类是由type造的。于是出现了一个非常奇特的结构：type是它自己的类，同时type又是所有类的类。

我第一次跑出这些结果的时候，第一反应是：这不就是递归吗？为什么没有无限递归下去？这恰恰是“自举结构”最精髓的地方——它在体系内部完成闭环，不需要一个体系外的“裁判”。

1.2 什么叫“构建规则也由对象描述”

做一个不太严谨但很直观的类比。写文档的时候，我们经常用Markdown语法描述一篇文档的结构，但Markdown语法本身也是一篇文档，它也可以用Markdown来描述。你拿#来定义标题，而这个#的语法规则，也可以用一篇Markdown写出来。

Python的对象模型就是这样：用来创建对象的规则（类），本身也是一个对象；用来创建类的规则（元类，默认是type），本身还是一个类；而这个元类的构造规则，又回到了type自己身上。整个体系在自身内部互相指涉，完成了自洽。

这对日常开发的影响是深远的。因为类和普通对象遵守同一套规则，所以你就能对类做很多“对普通对象才能做的事”：动态给类加方法、把类当作参数传递、在运行时创建全新的类。这些能力在其他很多语言里是不可想象的，但在Python里是家常便饭。例如：

python复制def dog_speak(self):
    return "汪汪"

# 运行时给类动态绑方法
Dog = type("Dog", (), {"speak": dog_speak})
d = Dog()
print(d.speak())  # 汪汪

这里type(...)的用法不是查看类型，而是在“创建类”。类被当成了普通对象来构造，这正是对象模型自举结构带来的直接红利。

1.3 自举不是Python的专利，但Python把它做到了极致

聊到这里有人会问：别的动态语言不也这样吗？确实，Ruby的对象模型也非常优雅，Smalltalk更是这个思想的鼻祖。但Python的特殊之处在于，它把“自举”这件事做得极其彻底、极其一致：

• 一切皆对象，包括类、函数、模块、异常类型；
• 所有对象的创建路径都收敛到type上；
• type这个“创建者”自身又遵守对象规则。

一致性带来的是心智负担的降低。你只需要掌握一套规则，就能推演出绝大多数行为。我在写爬虫框架、写量化回测系统的时候，经常利用这种一致性去批量化地生成类、动态注册策略，省掉了大量重复代码。说实话，理解了这个结构之后，再回头看很多框架源码，有种“任督二脉被打通”的感觉，以前觉得是黑魔法的地方，其实都是对象模型自举的必然结果。

2. type 和 object：对象模型里最核心的循环

2.1 用代码验证那个绕口令

现在进入整个对象模型最核心的“循环”。用一段代码就能验证：

python复制print(isinstance(object, type))  # True：object是type的实例
print(isinstance(type, object))  # True：type是object的子类实例？
print(issubclass(type, object))  # True：type继承自object
print(type.__base__)             # <class 'object'>：type的基类是object
print(object.__class__)          # <class 'type'>：object的类是type

这段代码输出了一个循环关系：object的类是type，type的基类是object。也就是说，object是type创建出来的，而type又是从object继承下来的。这像一个首尾相接的莫比乌斯环，先有鸡还是先有蛋的问题在逻辑上被绕成了一个自洽的结构。

很多初学者在这里会卡住：既然type继承自object，那至少object应该先存在；但object的类型又是type，那说明type也得先存在。到底谁先谁后？答案很朴素：在CPython的实现里，这两个对象是在解释器启动阶段用C语言静态定义好的，它们是解释器内部预先分配好的结构体，不经过常规的“创建流程”。用代码模拟这套自举会有鸡生蛋的问题，但在C层面，二者同时“出生”，互相引用地址，循环就被打破了。

2.2 CPython 是怎么在 C 层打破循环的

如果有耐心去看CPython源码，会发现type对应的是PyType_Type这个结构体，object对应的是PyBaseObject_Type这个结构体。它们在Objects/typeobject.c和Objects/object.c里被静态定义。

关键在于，这两个结构体在定义时就互相“指名道姓”：

• PyBaseObject_Type（也就是object）的ob_type字段指向&PyType_Type；
• PyType_Type（也就是type）内部的tp_base字段指向&PyBaseObject_Type。

它们不是先创建一个再创建另一个，而是在C语言层面同时声明好两个结构体，再用指针交叉引用。这也是唯一能在“逻辑先有鸡还是先有蛋”之外给出实现答案的办法——底层直接用内存地址完成互指，到了Python层面我们看到的就是那个漂亮的循环。

我当初读源码时最大的感悟是：Python并不神奇到能违反逻辑，它只是在更底层把矛盾消化掉了。理解这一点后，再看文档里轻描淡写的“type is its own metaclass”“object is the base of all classes”，就不会觉得是天书了。

2.3 为什么这个循环没有导致无限递归

另一个常见的追问是：如果type的类是自己，那type创建type的过程中会不会无限递归？

实际上不会。关键点在于：对于内置类型，它们的“创建过程”并不是通过元类的__call__走一遍正常的实例化流程，而是在解释器启动时就“凭空”设置好的。换句话说，type这个对象已经静态存在了，它不是被“实例化”出来的，而是被C结构体直接定义出来的。Python层面看到的type(type) is type，只是一个既成事实，并不存在一个“type创建type”的动态过程。

打个比方：数学公理系统里，皮亚诺公理定义了自然数，但你不会去追问“公理本身是不是自然数”。公理是体系的起点，type和object就是这个对象模型体系的两个互相锚定的公理。它们的存在保证了整个体系不自相矛盾，而它们自身不再需要更上层的创建者。只要理解了这一点，对象模型的自举结构就理解了一大半。

3. 元类：自举结构给你的一把钥匙

3.1 type() 的第二种用法：动态创建类

自举结构最大的实际价值，就是元类机制。而元类入门的第一课，往往就是type()的第二种用法。

我们平时写类，用的是class关键字：

python复制class Dog:
    def speak(self):
        return "汪汪"

但class关键字本质上是一次语法糖调用。你可以用type手动完成同样的事情：

python复制def speak(self):
    return "汪汪"

Dog = type("Dog", (), {"speak": speak})
d = Dog()
print(d.speak())  # 汪汪

type的第二个用法接收三个参数：名字、基类元组、命名空间字典。三个参数分别对应了类的“名字”、“从哪里继承”、“有哪些属性和方法”。这其实就是class语句背后的真正执行逻辑。

这一点对理解对象模型至关重要：既然class语句的本质是“调用元类创建一个类对象”，那只要替换掉默认的元类type，就能在类创建时插入自定义行为。这就是元类编程的入口。

3.2 自定义元类的三钩子：new、init、call

自定义元类最常见的写法是继承type：

python复制class MyMeta(type):
    def __new__(mcs, name, bases, namespace):
        print(f"创建类: {name}")
        namespace["created_by_meta"] = True
        return super().__new__(mcs, name, bases, namespace)

    def __init__(cls, name, bases, namespace):
        super().__init__(name, bases, namespace)
        print(f"初始化类: {name}")

这里有两个关键钩子：

• __new__在类对象被创建之前调用，负责真正“造”出这个类，返回值就是类对象本身；
• __init__在类对象创建之后调用，负责对类对象做初始化，比如给类添加属性、注册到某个全局表里。

再往外还有第三层钩子__call__，它控制的是“创建类的实例”的行为。因为元类是一个类，而所有类都是元类的实例，所以当你执行Dog()时，实际调用的是元类MyMeta.__call__：

python复制class MyMeta(type):
    def __call__(cls, *args, **kwargs):
        print(f"准备创建实例: {cls.__name__}")
        instance = super().__call__(*args, **kwargs)
        print(f"实例创建完成: {instance}")
        return instance

这三个钩子分别管三件不同的事：__new__管类怎么被创建，__init__管类创建后怎么被修饰，__call__管这个类的实例如何被创建。理解了它们的层次关系，元类就不再是黑魔法了。

3.3 元类和装饰器怎么分工

写代码的时候经常面临一个选择：这个功能该用装饰器还是元类？我的经验是看“作用时机”和“作用对象”。

• 装饰器作用于函数或类已经存在之后，对它做包装或增强，不改变其创建过程；
• 元类作用于类的创建过程本身，可以在类诞生前修改它的骨架。

举个例子。给类自动加上字段校验，用装饰器也行：

python复制def add_validation(cls):
    original_init = cls.__init__
    def wrapped(self, **kwargs):
        for key, value in kwargs.items():
            if not isinstance(value, int):
                raise TypeError(f"{key} 必须是整数")
        original_init(self, **kwargs)
    cls.__init__ = wrapped
    return cls

@add_validation
class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

但如果你希望每个子类在定义时自动继承校验逻辑，装饰器就有点笨拙了，因为你没法保证所有子类都记得加上这个装饰器。这时候元类的优势就体现出来了：

python复制class ValidateMeta(type):
    def __call__(cls, *args, **kwargs):
        for key, value in kwargs.items():
            if not isinstance(value, int):
                raise TypeError(f"{key} 必须是整数")
        return super().__call__(*args, **kwargs)

class Base(metaclass=ValidateMeta):
    pass

class Point(Base):
    def __init__(self, x, y):
        self.x = x
        self.y = y

只要继承Base，校验逻辑就自动生效，不需要子类做任何额外声明。这是元类在框架设计中常被选中的原因——它能沿着继承链自动“传染”。

3.4 init_subclass 和 set_name：元类的轻量替代

不过我得说句公道话：不是所有场景都需要上元类。Python 3.6之后引入了__init_subclass__，很多以前必须用元类才能实现的“子类创建时自动处理”的功能，现在用这个钩子就能搞定，代码还更好读。

python复制class Base:
    registry = {}

    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        Base.registry[cls.__name__] = cls

class StrategyA(Base):
    pass

class StrategyB(Base):
    pass

print(Base.registry)
# {'StrategyA': <class '__main__.StrategyA'>, 'StrategyB': <class '__main__.StrategyB'>}

每当有子类定义时，__init_subclass__就会被自动调用，天然适合做策略注册表。相比之下，元类的写法虽然也能实现，但要对继承机制有更深的理解。

还有__set_name__也是自举结构里很妙的一环。描述符类定义__set_name__之后，在宿主类创建时会回调这个方法，告诉描述符“你被赋值到了哪个类的哪个属性上”。比如：

python复制class PositiveNumber:
    def __set_name__(self, owner, name):
        self.name = f"_{name}"

    def __get__(self, instance, owner):
        return getattr(instance, self.name)

    def __set__(self, instance, value):
        if value <= 0:
            raise ValueError("必须为正数")
        setattr(instance, self.name, value)

class Order:
    price = PositiveNumber()
    count = PositiveNumber()

如果没有__set_name__，你就只能在__init__里手动给描述符起名字，繁琐且易错。而这个机制之所以存在，本质上也是因为类创建过程是可编程、可回调的——对象模型的自举结构为这些钩子提供了运行环境。

4. 自举结构在真实项目里的打法

4.1 ORM 框架：Django 的 ModelBase

理论说了一堆，看看真实框架是怎么用的。以Django为例，任何模型类都继承自models.Model，而这个Model背后挂着一个元类ModelBase。

写过一个最简单的模型：

python复制from django.db import models

class Person(models.Model):
    name = models.CharField(max_length=50)
    age = models.IntegerField()

在类定义时，ModelBase会做大量事情：扫描命名空间里的Field对象、根据数据库配置生成对应的_meta元信息、绑定数据库表名、创建管理器（objects）、处理继承关系，等等。你写的那几行字段声明，在元类手里被扩展成了一个完整的数据映射结构。

这时候回头看对象模型的自举结构，就很容易理解Django的设计：既然类也是对象，那框架就能在“类诞生”这个瞬间插入逻辑；既然CharField、IntegerField本身也是对象，那元类就能在类命名空间里识别并收集它们。整个设计建立在一个“类与属性皆可编程”的模型之上，而这正是Python对象模型自举结构给的底气。

4.2 套路化的元类实战：单例、注册表、路由收集

抛开大型框架，元类在日常项目中提炼出的“套路”其实就那么几种。我总结了一下最常见、最实用的三个：

套路一：元类实现单例。 我在写配置管理组件时最常这么干：

python复制class SingletonMeta(type):
    _instances = {}

    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super().__call__(*args, **kwargs)
        return cls._instances[cls]

class AppConfig(metaclass=SingletonMeta):
    pass

关键点在于把判断逻辑放在元类的__call__上，这样无论怎么实例化，拿到的都是同一个对象。

套路二：类注册表。 写插件系统或者策略系统时特别常见：

python复制class RegistryMeta(type):
    registry = {}

    def __new__(mcs, name, bases, namespace):
        cls = super().__new__(mcs, name, bases, namespace)
        if name != "BasePlugin":
            mcs.registry[name] = cls
        return cls

class BasePlugin(metaclass=RegistryMeta):
    pass

class HttpPlugin(BasePlugin):
    pass

class FtpPlugin(BasePlugin):
    pass

print(RegistryMeta.registry)
# {'HttpPlugin': <class '...'>, 'FtpPlugin': <class '...'>}

模块一加载，所有插件类就自动进入注册表，无须手动登记。做爬虫框架的时候，我用这套模式把不同类型的采集器自动注册到调度中心，新增采集器只需要写一个类，改一行注册配置都不需要。

套路三：路由或校验逻辑自动收集。 类似Django的urls、Flask的route，本质都是在类创建时把信息收集到某个全局结构中。用元类实现的话，子类定义时携带的路由前缀、字段约束等元信息都会被自动拾取、统一处理。

4.3 日常脚本和数据工程里的对象模型思维

有人会觉得，我就写点数据分析脚本、做点自动化测试，对象模型自举跟我有什么关系？其实关系很大。

举个实际例子。用pandas做多策略量化回测时，经常要为不同交易策略写逻辑类似的类。利用“类也是对象”的特性，我可以写一个工厂函数，按配置动态生成类：

python复制def build_strategy(name, rule_func, stop_loss=None):
    attrs = {
        "name": name,
        "rule_func": rule_func,
        "stop_loss": stop_loss,
        "run": lambda self, data: self.rule_func(data),
    }
    return type(name, (BaseStrategy,), attrs)

ma_cross_strategy = build_strategy(
    "MA交叉", ma_rule, stop_loss=0.05
)

这样策略定义就变成了数据驱动，而不是一堆重复的类声明。同样的思路在爬虫项目里也很常见：不同的目标网站往往只需要换一套解析规则和请求参数，动态生成类能省掉大量样板代码。

还有一点值得说：int()、str()、list()这些类型转换，很多人当成“函数”用，但它们其实是类的构造器。理解了对象模型，就能明白“类型转换”的本质是“创建一个对象”，这也解释了为什么int("123")和int(3.7)返回不同类型的内部表示时，走的都是类实例化的路径。可以说，对象模型的理解程度，直接决定了你能否从“会写Python”进化到“理解Python”。

5. 对象模型自举的坑与排查技巧

5.1 元类冲突：TypeError: metaclass conflict

最典型的报错长这样：

python复制class MetaA(type): pass
class MetaB(type): pass

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

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

原因很简单：C同时继承两个基类，而两个基类的元类不同，Python不知道用谁来创建C。更准确地说，它在寻找一个同时兼容MetaA和MetaB的元类，找不到就直接报错。

解决方案有两种。一是让其中一个元类继承另一个：

python复制class MetaA(type): pass
class MetaB(MetaA): pass  # MetaB 是 MetaA 的子类

二是给新类显式指定一个能兼容所有基类元类的元类：

python复制class MetaAB(MetaA, MetaB): pass
class C(A, B, metaclass=MetaAB): pass

排查时记住一条原则：子类的元类必须是基类元类的子类（或相同）。用issubclass去验证一下就能定位问题。

5.2 new 和 init 的顺序陷阱

我在自己写元类时踩过一次坑：在元类的__new__里给类加属性，结果发现某些属性在__init__里访问不到。

后来梳理清楚了：__new__的返回值会作为类对象传给__init__。如果在__new__里没有正确调用super().__new__，或者返回的不是类对象，__init__可能根本不会被调用。另一个容易忽视的点是，__new__里的namespace是类命名空间的原始字典，你在里面放的属性，到__init__执行时已经被转化成类的属性了，但要访问它们应该用getattr(cls, "attr_name")，而不是从namespace里取。

再提醒一个隐蔽问题：元类__call__返回的如果不是类的实例，那么类的__init__不会被执行。比如在__call__里判断缓存后直接返回已有对象，这时候__init__被跳过，如果你在__init__里做了重置操作，就会产生“对象状态没更新”的诡异Bug。

5.3 用 type 动态造类时的三个注意点

动态用type(name, bases, namespace)创建类，看起来很爽，但有几个细节不注意到会翻车：

第一，namespace里的属性名必须是字符串，方法得是函数对象。写成字典字面量时，务必注意键是字符串，值是函数或属性。

第二，动态创建的类不会有专门的__module__值，某些依赖模块名做序列化或调试的工具会出问题。建议手动指定：

python复制MyClass = type("MyClass", (), {"x": 1})
MyClass.__module__ = "__main__"

第三，继承时不要忘了调用父类初始化。动态类同样遵守MRO规则，如果你在namespace里定义了__init__并覆盖了父类逻辑，又不调用super().__init__()，就会遇到“子类属性没初始化”的问题。这跟手写class子类时的规则完全一致，只是在动态创建时更容易被遗忘。

5.4 常见问题速查

我把前面提到的坑整理成一张表，方便以后排查：

最后说点实在的

研究对象模型自举结构，我的收获并不仅仅是搞懂了元类怎么写。它改变的是我看Python代码的方式——写类时我会想：这个类在创建时经历了什么？能不能利用这个过程自动化一些事情？读框架源码时我会想：它在这里用元类要解决什么问题，能不能用更轻量的__init_subclass__替代？

我个人在实际操作中的体会是，这个主题值得反复读、反复验证，不要满足于“知道结论”，而是要亲手在解释器里把type、object、__class__、__base__这些属性一个个敲出来，甚至用vscode或pycharm打断点观察类创建的过程。踩过几轮坑之后，你会发现之前觉得玄乎的高级特性，全都变得顺理成章了。

如果这篇内容对你有帮助，建议下一个动手实验就用元类写一个小的策略注册器。这个内容后续还可以向“描述符协议”和“属性查找顺序”扩展——理解了对象模型的自举结构，再去看描述符，你会觉得那些钩子设计得不能再自然了。