__init_subclass__ 更合适，因其在子类定义时自动触发、语义清晰、调试友好，能实现“一定义就报错”；而元类易被绕过，校验时机晚、堆栈混乱，且需手动处理MRO和命名空间干扰。
为什么 __init_subclass__ 比元类更合适强制校验
直接用元类做方法存在性校验，容易绕过（比如子类动态添加方法、或继承链中中间类已实现但未被检查），而 __init_subclass__ 是 Python 3.6+ 的标准机制，在每次创建子类时自动触发，语义清晰、干扰少、调试友好。它不侵入实例创建流程，也不需要重写 __new__ 或 __call__，出错时堆栈也干净。
常见错误现象：TypeError: Can't instantiate abstract class X with abstract methods Y —— 这是 abc.ABC 的报错，但它只在实例化时才触发，无法阻止“定义了但没实现”的子类被成功定义；而我们想的是：**一定义就报错**。
- 使用场景：框架基类（如插件接口、事件处理器）、团队协作中约定的契约式 API
- 参数差异：
__init_subclass__接收子类的**kwargs，可用于传入校验开关、白名单等配置 - 性能影响：几乎为零，仅在类定义时执行一次
如何用 __init_subclass__ 校验必须实现的方法
核心思路：在父类中覆写 __init_subclass__，遍历预设的方法名列表，检查子类是否在其 __dict__ 中显式定义（排除从父类继承来的）。
示例：
class PluginBase:
def __init_subclass__(cls, **kwargs):
super().__init_subclass__(**kwargs)
required = ["setup", "run", "teardown"]
missing = []
for method in required:
# 只检查子类自己定义的，不查继承链
if not (method in cls.__dict__ and callable(cls.__dict__[method])):
missing.append(method)
if missing:
raise TypeError(f"Class {cls.__name__} must implement {missing}")
<p>class MyPlugin(PluginBase):
def setup(self):
pass
def run(self):
pass</p><h1>忘了 teardown → 定义时立刻报错</h1><p></p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill11526" title="Python Hardener"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="Python Hardener" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill11526" title="Python Hardener" class="overflowclass">Python Hardener</a>
<p class="overflowclass">通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 Python 脚本。</p>
</div>
<a rel="nofollow" href="/xiazai/skill11526" title="Python Hardener" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 用
cls.__dict__而非getattr(cls, ...)，避免误判继承来的方法 - 必须加
callable(...)判断，否则属性名冲突（如变量名和方法同名）会漏检 - 如果允许子类用
@classmethod或@staticmethod实现，callable仍成立，无需额外处理
兼容旧版 Python 或需更细粒度控制时，元类怎么写
若项目仍在用 Python 3.5 或以下，或需拦截类创建全过程（比如同时校验方法 + 修改类属性），才考虑自定义元类。此时关键点是：在元类的 __new__ 中完成校验，而非 __init__（因为 __init__ 执行时类对象已构建完毕，报错后类名仍会存在于命名空间中）。
示例：
class EnforceMethodsMeta(type):
def __new__(mcs, name, bases, namespace, **kwargs):
cls = super().__new__(mcs, name, bases, namespace)
# 只对直接继承该元类的类校验，跳过基类自身
if bases and PluginBase in bases:
required = ["setup", "run", "teardown"]
missing = [m for m in required if m not in namespace or not callable(namespace[m])]
if missing:
raise TypeError(f"{name} must implement {missing}")
return cls
<p>class PluginBase(metaclass=EnforceMethodsMeta):
pass
</p>
- 注意判断条件
if bases and PluginBase in bases，防止校验元类自身或无关基类 - 校验逻辑放在
__new__，确保类对象未被注册到全局命名空间前就失败 - 兼容性影响：Python 2 不支持关键字参数元类语法（
metaclass=...），需用__metaclass__类变量，此处不展开
容易忽略的边界情况
校验逻辑看似简单，但实际踩坑多在细节：
- 子类用
__getattr__动态提供方法 →cls.__dict__查不到，校验会误报；这种情况应明确禁止，或改用文档/类型提示约束 - 方法被装饰器包裹（如
@property、@cached_property）→callable(namespace[m])仍为True，没问题；但@abstractmethod本身不满足 callable，需单独识别ABCMeta相关标记 - 子类是
typing.Protocol→ 它不参与运行时继承，__init_subclass__不触发，这类“鸭子类型”契约不在本方案覆盖范围内 - 测试时用
types.new_class或type(...)构造类 → 绕过__init_subclass__，需在 CI 中禁用或补充单元测试校验
最常被跳过的其实是校验时机：想“定义即报错”，就必须在类对象诞生的那一刻介入，而不是等 import 或实例化——这点上 __init_subclass__ 天然可靠，元类则要盯紧 __new__ 的位置。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
