如何通过Python元类（Metaclass）在类创建时动态修改类行为？

元类是 Python 类构造过程中最底层的“幕后黑手”——它在类定义结束、实例尚未创建时触发，其 `__new__` 和 `__init__` 分别用于修改命名空间和验证类结构。换句话说，它是唯一能拦截并修改类构建过程的机制，也是很多框架（如 Django、SQLAlchemy）的基石。

元类触发时机：类定义结束但实例尚未创建时

元类的 `__new__` 和 `__init__` 在 `class` 语句执行完、类对象刚生成时立即调用。此时类体已解析完毕，但任何实例都还没出现。这可不是装饰器那种“事后补丁”——元类是真真切切参与类构建的，是在类的“出生证明”上直接动手。 常见误区是把元类当成类装饰器用。比如有人在 `__init__` 里试图给未来实例加属性，结果发现实例根本没继承到；或者以为元类能干预 `__call__` 之外的方法调用。敲黑板：它只管“造类”，不管“造实例”之后的逻辑。 * `__new__(mcs, name, bases, namespace)`：必须返回一个类对象，常用来重写 `namespace`（比如注入方法、改字段名） * `__init__(cls, name, bases, namespace)`：接收已创建好的类对象 `cls`，适合做验证或轻量级修补（不能改 `__dict__` 中的不可变项） * 如果两者同时定义，`__new__` 必须先返回一个类，`__init__` 才会被调用；跳过返回值会触发 `TypeError`

动态注入方法：用 namespace 拦截并增强类定义

想让所有继承某元类的类自动带一个 `dump()` 方法？别在基类里硬编码了，直接在元类 `__new__` 中往 `namespace` 字典里塞函数就行： ```python def dump(self): return {k: v for k, v in self.__dict__.items() if not k.startswith('_')} class AutoDumpMeta(type): def __new__(mcs, name, bases, namespace): namespace['dump'] = dump return super().__new__(mcs, name, bases, namespace) ``` 注意：`namespace` 是类体中顶层语句的符号表（不包含继承来的属性）。直接修改它比后期用 `setattr(cls, ...)` 更可靠——后者可能被 `__slots__` 拦截，而前者在类构建前就生效了。 几个实用的“潜规则”： * 避免覆盖用户已定义的同名方法：先检查 `'dump' not in namespace` 再注入 * 注入的函数若引用了 `self`，它就是普通实例方法，无需额外绑定 * 不要在 `namespace` 中放复杂逻辑（比如循环 import），因为元类执行时模块可能还没完全加载

强制接口检查：在 __init__ 中验证类是否实现必需方法

想确保所有使用 `ValidatedAPI` 元类的类都实现了 `handle()` 和 `schema()`？在 `__init__` 里查 `cls` 的 `__dict__` 或用 `hasattr` 即可： ```python class ValidatedAPI(type): def __init__(cls, name, bases, namespace): super().__init__(name, bases, namespace) if not (hasattr(cls, 'handle') and callable(getattr(cls, 'handle'))): raise TypeError(f"{name} must implement 'handle()' method") if not hasattr(cls, 'schema'): raise TypeError(f"{name} must define 'schema' attribute") ``` 这里用 `__init__` 而非 `__new__`，是因为方法是否可调用、属性是否存在，需要等类对象完整构建后才能准确判断。`__new__` 阶段 `namespace` 还没合并父类内容，检查结果不可靠。 再补充几个实战要点： * 用 `getattr(cls, 'xxx', None)` 替代直接访问，防止 AttributeError 干扰验证逻辑 * 如果允许子类继承实现，检查时应排除抽象基类（`inspect.isabstract(cls)`） * 报错信息里带上 `name`（类名），否则调试时你都不知道是哪个类踩了雷

与 __init_subclass__ 的关键区别：谁负责、何时生效

Python 3.6+ 引入的 `__init_subclass__` 看起来像是元类的“简化版”，但它只对**直接子类**生效，而且调用时机晚于元类：`__init_subclass__` 在子类创建完成后才触发，无法修改子类的 `namespace` 或阻止其创建。 举个例子：你想禁止某个基类被多重继承。元类能在 `__new__` 中检查 `len(bases) > 1` 并直接 `raise`；而 `__init_subclass__` 此时类已经造好了，只能事后警告，无力拦截。 那么什么时候该用哪个？ - 需要修改类结构（增删方法、改 `__slots__`、动态设 `__annotations__`）→ 选元类 - 只需对子类做轻量初始化（比如注册到全局表、打日志）→ 优先用 `__init_subclass__`，更简洁易读 - 两者混用时，元类的 `__new__`/`__init__` 一定先执行，`__init_subclass__` 最后调用 元类真正的复杂点不在语法，而在责任边界——它介入的是 Python 类模型最底层的构造过程。一旦出错，往往表现为类导入失败或 `TypeError: metaclass conflict`。这类问题很难通过常规调试定位，得从 `type()` 调用链一步一步反推。说到底，用好元类需要对 Python 对象模型有精准的理解，而不是简单地记住几个模板代码。