__init_subclass__ 钩子在 Python 3.6 中作为 PEP 487 的一部分引入。在此之前，任何想要在子类化时执行操作的类，例如注册、验证或自动字段收集，都必须声明自定义 metaclass。虽然 metaclass 功能强大，但在多重继承场景中会造成摩擦，因为它们会冲突，除非经过仔细协调。这个新的钩子允许基类参与子类初始化，而不强迫整个层次结构采用特定的 metaclass，从而简化了像 Django ORM 和 SQLAlchemy 这样的框架，它们之前依赖于复杂的 metaclass 技巧。
当类 B 从基类 A 继承时，框架开发人员通常需要在定义类 B 时执行逻辑——在创建任何实例之前。例如，一个 ORM 可能需要收集 B 所有列定义并将其存储在注册表中。使用 metaclass 要求 A 具有 type 或一个自定义的 metaclass 作为其 metaclass，当 B 也需要使用不同的 metaclass（例如来自 ABC 或另一个框架）时，这就会变得问题重重。这会导致很难解决的 metaclass 冲突错误。此外，metaclass 的 __new__ 在类命名空间完全填充之前运行，使得很难检查最终的类属性。
Python 提供了 __init_subclass__ 类方法。当一个类定义了这个方法时，它会在每当创建以定义类作为直接父类的类时自动调用。该钩子将新创建的子类作为第一个参数，后面跟着在类定义行中传递的任何关键字参数（例如，class B(A, keyword=value)）。
class RegistryBase: _registry = {} def __init_subclass__(cls, category="default", **kwargs): super().__init_subclass__(**kwargs) print(f"Registering {cls.__name__} under category '{category}'") cls._registry[cls.__name__] = {"class": cls, "category": category} class Plugin(RegistryBase, category="audio"): pass class Effect(Plugin, category="reverb"): pass
与在类创建期间运行的 metaclass __new__ 不同，__init_subclass__ 在类对象完全构造之后运行。这使得钩子可以安全地检查 cls.__dict__、方法和注解。钩子还尊重 MRO，确保在调用 super() 时，父类注册在子类逻辑之前发生。
在一个大型音频处理 SaaS 平台中，工程团队需要实现一个插件系统，让第三方开发者可以通过从基类 AudioEffect 继承来定义音频效果。每个子类需要自动注册到具有元数据（如 effect_name、latency_ms 和 category）的全球效果目录中。问题是该平台已经使用 SQLAlchemy 声明式基类（使用 metaclasses）作为数据库模型，而某些音频效果需要同时从 AudioEffect 和 SQLAlchemy 模型继承。为 AudioEffect 引入自定义 metaclass 导致与 SQLAlchemy 的 DeclarativeMeta 发生 metaclass 冲突，破坏了应用程序的启动。
第一个方法涉及使用装饰器进行手动注册。开发者在每个类定义上方写 @register_effect。这有效，但容易出错；开发者经常忘记这个装饰器，导致生产环境中缺失效果。而且这也要求他们在装饰器参数和类定义中重复元数据，违反了 DRY 原则。
第二个方法尝试使用一个通用的 metaclass，它同时从 DeclarativeMeta 和 EffectMeta 继承。这解决了直接的冲突，但创建了脆弱的依赖关系。每当 SQLAlchemy 更新其内部 metaclass 逻辑时，平台就会崩溃。它还迫使所有效果类都成为数据库模型，这对于轻量级的客户端效果来说并不合适。
第三个方法利用了 __init_subclass__。基类 AudioEffect 定义了 __init_subclass__ 来捕获在类定义期间传递的关键字参数，例如 effect_id 和 version。当开发者编写 class Reverb(AudioEffect, effect_id="rvb-01", version=2) 时，该钩子会自动验证 ID 的唯一性并在线程安全的 WeakValueDictionary 注册表中注册该类。这完全避免了 metaclass 冲突，因为 __init_subclass__ 是一个常规类方法，与任何 metaclass 协作。
团队选择了第三种方案。它保持了与 SQLAlchemy 的兼容性，消除了对装饰器的需求，并确保在导入时自动注册。结果是一个“只需工作”的插件系统——开发者只需继承和内联声明参数。该系统成功注册了 150 多个效果，而没有发生过一次 metaclass 冲突，并且与 metaclass 方法相比，启动时间提高了 40%，因为减少了 MRO 计算的复杂性。
为什么 __init_subclass__ 必须始终调用 super().__init_subclass__()，即使父类没有定义它？
候选人常常认为，由于 object 并未定义 __init_subclass__，因此这个调用是可选的。然而，在多重继承场景中，未能调用 super() 可能会中断也实现此钩子的兄弟类的链。Python 的协作多继承要求每个参与者在菱形中调用 super()，以确保层次结构的所有分支都执行其初始化逻辑。如果 A 和 B 都定义了 __init_subclass__，而 C(A, B) 仅调用了 A 的钩子，B 的注册逻辑将会被悄悄跳过，这会导致插件系统中的微妙错误。
__init_subclass__ 如何处理未被方法签名消耗的关键字参数，为什么 **kwargs 是强制性的？
当一个子类以关键字参数定义（例如 class D(C, custom_arg=5)）时，这些参数会传递给 __init_subclass__。如果方法签名不包含 **kwargs 以捕获和传播未使用的参数，并且 MRO 中的另一个类也定义了 __init_subclass__，则会发生 TypeError，因为 Python 尝试将关键字参数传递给下一个钩子，但该钩子并不接受。因此，强健的实现必须始终包含 **kwargs，并将其传递给 super().__init_subclass__(**kwargs) 以支持不同层级消耗不同参数的协作继承。
__init_subclass__ 是否可以修改类命名空间或动态添加方法，__slots__ 的影响是什么？
候选人常常将 __init_subclass__ 与 metaclass 的 __new__ 混淆。由于 __init_subclass__ 在类完全创建之后运行，因此它无法在创建之前修改类字典（与 __prepare__ 或 metaclass 的 __new__ 不同）。然而，它可以使用 setattr(cls, name, value) 动态地添加属性。问题出在 __slots__：如果父类使用了 __slots__，子类将继承这个约束。尝试在 __init_subclass__ 中使用 setattr 向一个有槽的类添加新属性将引发 AttributeError，除非子类本身定义了 __slots__ 或 __dict__。这样的限制迫使架构师在使用 __init_subclass__ 进行注册/元数据和使用 metaclasses 进行真实的类主体结构修改之间进行选择。