元类的 __new__ 是控制类生成的第一道关卡，必须在此阶段动态干预（如添加属性、校验方法名），而 __init__ 已无法修改类结构；__prepare__ 用于预置命名空间，是唯一能在类体执行前介入的钩子。
元类的 __new__ 方法是控制类生成的第一道关卡
类对象在 Python 中本质是元类的实例，而默认元类 type 的 __new__ 负责真正构造类。想动态干预——比如自动添加属性、校验方法名、禁止某些继承——必须重写这个方法，而不是 __init__（后者执行时类已生成完毕，改不了 __dict__ 结构或方法解析顺序）。
常见错误是把逻辑全塞进 __init__，结果发现 __annotations__ 已冻结、__mro__ 无法调整、装饰器没生效——因为那些事得在类对象诞生前做。
-
__new__接收四个参数：cls（元类自身）、name（类名）、bases（父类元组）、namespace（待生成类的命名空间字典） - 必须显式调用
super().__new__(cls, name, bases, namespace)返回类对象，不能只返回None或其他值 -
namespace是普通 dict，可直接增删改；但注意：其中的函数对象尚未绑定，self还不存在，别试图调用它们
用 __prepare__ 预置有序/带验证的命名空间
默认情况下，类体语句执行前，namespace 是个空 dict，键插入顺序不保留（Python 3.7+ dict 本身有序，但元类层面不应依赖此行为）。若需按定义顺序处理字段（如 ORM 模型）、或拦截非法键名（如禁止下划线开头的方法），应在元类中定义 __prepare__。
它必须返回一个映射对象（如 dict 子类或 collections.OrderedDict），且在类体执行前被调用。这是唯一能在类定义阶段就介入命名空间构建的钩子。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
-
__prepare__是类方法，第一个参数是元类cls，后面可加任意关键字参数（通过class MyClass(metaclass=MyMeta, strict=True):传入） - 返回的映射对象会用于执行类体代码，所有赋值都落在它上面，后续
__new__收到的就是这个对象 - 示例：返回
collections.OrderedDict()可保证字段注册顺序；返回自定义 dict 子类可在__setitem__中抛出TypeError拦截非法属性名
避免在元类中修改 __init__ 或 __new__ 导致实例化异常
很多人想“统一给所有子类加初始化逻辑”，于是直接在元类的 __new__ 里往 namespace 塞一个新 __init__。这看似方便，实则危险：它会覆盖用户明确定义的 __init__，且无法兼容 __init_subclass__ 或数据类（@dataclass）的自动注入。
真正安全的做法是：在元类中不碰 __init__，而是提供可组合的基类或装饰器；若必须干预，应检查 namespace 是否已含 __init__，仅在未定义时注入，并确保其调用 super().__init__()。
- 更推荐方案：用元类设置一个类属性（如
_required_fields = [...]），再由基类__init__读取并校验，解耦生成期与运行期逻辑 - 若硬要注入，务必用
types.FunctionType构造新函数，并显式绑定__qualname__和__module__，否则 traceback 会显示<lambda>或丢失上下文 - 注意：元类不能改变类的
__call__行为（那是type.__call__的职责），试图重写它会导致TypeError: cannot create 'X' instances
调试元类时最常遇到的 NameError 和继承链断裂
写完元类一跑就报 NameError: name 'SomeClass' is not defined？大概率是元类在 __new__ 中过早访问了尚未定义的名称——比如试图从 namespace 里取某个变量，但它实际是在类体后半段才赋值的。另一个高频问题是多重继承下元类冲突：class A(metaclass=MetaA) 和 class B(metaclass=MetaB) 的子类 C(A, B) 会因元类不兼容而失败。
- 永远假设
namespace是“正在构建中”的快照，不要依赖其中未声明的符号；需要跨作用域引用，应推迟到类创建后（如在__init_subclass__中） - 解决元类冲突：让
MetaB继承MetaA，或实现__init_subclass__兼容逻辑；更稳妥的是避免多个元类，改用类装饰器组合功能 - 调试技巧：在元类方法开头加
print(f"{method_name}: {name}, bases={bases}")，比打日志到终端更直观；用breakpoint()进入交互式调试时，注意namespace是 dict，但里面函数对象的__code__.co_names才反映真实引用
元类不是语法糖，它是 Python 对象模型的底层接口。每次修改 __new__，你都在重写 Python 解释器对“类是什么”的理解——这意味着任何疏漏都会在实例化那一刻才暴露，且堆栈极深。动手前先问：这件事真的不能用类装饰器、__init_subclass__ 或描述符解决？
