Final注解仅是类型检查提示，运行时无法阻止继承；真正可靠的拦截机制是重写__init_subclass__方法，在子类定义时主动抛异常。
Python里Final注解根本不能阻止类被继承
直接说结论：Final（来自typing模块）只是类型检查提示，运行时完全无效。你写class A(Final):语法本身就不合法；正确写法是class A: ...然后在类型检查器（如mypy）眼里标记它“不应被继承”，但Python解释器照常允许class B(A): pass执行成功。
常见错误现象：开发者以为加了Final就安全了，结果单元测试里子类悄悄覆盖了关键方法，线上出逻辑错却查不出原因。
-
Final只能用于变量、类、函数的**声明位置**，比如CONSTANT: Final = 42或class MyClass: ...; MyClass.__final__ = True（不推荐） - 对类使用
Final需配合mypy静态检查，且必须显式启用--disallow-subclassing-of-final-classes - 即便mypy报错，代码仍能
python run.py正常运行——这正是最危险的地方
想真正阻止继承？得靠__init_subclass__手动拦截
这是目前唯一能在运行时可靠拦截非法继承的机制。原理是在父类中重写__init_subclass__，检查调用上下文或白名单，不符合就抛异常。
典型使用场景：框架核心基类（如ORM Model、事件处理器）、加密密钥容器、单例控制类。
立即学习“Python免费学习笔记（深入）”；
- 在父类中定义
def __init_subclass__(cls, **kwargs):，里面加判断逻辑 - 可用
cls.__module__限制只允许特定包内继承，或用cls.__name__ in ALLOWED_SUBCLASSES硬编码白名单 - 注意：该方法在子类定义时触发（非实例化时），所以能最早拦截
- 别忘了调用
super().__init_subclass__(**kwargs)，否则可能破坏MRO或元类链
class SecureBase:
def __init_subclass__(cls, **kwargs):
if cls.__module__ != "myapp.core":
raise TypeError(f"Subclassing {cls.__name__} is not allowed outside myapp.core")
super().__init_subclass__(**kwargs)
__subclasses__()和__bases__不是防护手段，而是调试辅助
有人试图用SecureBase.__subclasses__()在初始化时扫描子类列表来“事后补救”，这完全不可靠——子类可能在任意时刻被动态创建（比如import触发、exec执行），且无法区分合法/非法继承。
更糟的是，依赖cls.__bases__检查父类是否含SecureBase，容易被绕过：class B(metaclass=type): ...可跳过常规继承链。
-
__subclasses__()返回当前已加载的所有直接子类，但无法感知未来定义的类 -
cls.__bases__只反映直接父类，对多层继承或元类构造无约束力 - 这些API适合日志审计或测试断言，绝不能用于运行时访问控制
为什么不用__new__或__metaclass__做更底层拦截？
理论上可行，但代价过高且兼容性差。自定义元类会干扰其他依赖type的库（如dataclasses、pydantic v2+、pytest fixtures），而重写__new__只能控制实例化，对类定义本身无能为力。
性能影响明显：每个类定义都触发元类逻辑，拖慢模块导入速度；在PyPy或某些嵌入式Python环境里还可能引发未定义行为。
- 除非你在开发Python解释器级框架（如Cython扩展、AST重写工具），否则不要碰元类
-
__new__对继承防护无效——子类定义不调用父类__new__ - 第三方类型检查器（如pyright）对自定义元类的支持远不如对
__init_subclass__稳定
importlib.import_module动态加载绕过。 
