__instancecheck__ 必须定义在元类中而非普通类里，因为 isinstance() 的查找逻辑是先获取对象所属类的元类，再调用该元类的 __instancecheck__ 方法；若直接写在类体中则完全不生效。
为什么 __instancecheck__ 不会在类定义里直接生效？
因为 __instancecheck__ 必须定义在**元类**中，而不是普通类里。Python 的 isinstance() 查找逻辑是：先检查对象的 __class__ 是否有对应的元类，再调用该元类的 __instancecheck__ 方法。如果你把它写在类体里，它根本不会被调用。
- 错误写法：
class A: def __instancecheck__(self, inst): ...→ 完全无效 - 正确路径：定义一个元类，重写它的
__instancecheck__，再让目标类使用这个元类 - 注意：元类必须继承
type，否则可能破坏类创建流程
怎么写一个可复用的元类来控制 isinstance 判断逻辑？
最常见需求是让某个类“假装”是另一个类型的实例（比如让 dict 实例通过 isinstance(obj, MyInterface)）。这时元类需捕获类型检查请求，并按自定义规则返回布尔值。
- 元类中
__instancecheck__的第一个参数是元类自身（即类对象），第二个是待检查的实例 - 不要在其中做耗时操作——
isinstance可能高频调用，影响性能 - 示例：让所有含
data属性且为 dict 的对象被视为DataContainer实例
class DataContainerMeta(type):
def __instancecheck__(cls, instance):
return hasattr(instance, 'data') and isinstance(instance.data, dict)
<p>class DataContainer(metaclass=DataContainerMeta):
pass</p><p>obj = type('Fake', (), {'data': {}})()
print(isinstance(obj, DataContainer)) # True
__instancecheck__ 和 __subclasscheck__ 有什么区别？
__instancecheck__ 控制 isinstance(obj, Cls)，而 __subclasscheck__ 控制 issubclass(Sub, Cls)。两者常成对出现，但用途完全不同。
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 如果你只改了
__instancecheck__，issubclass(MyClass, Target)仍走默认逻辑（即看 MRO） - 想让
MyClass在issubclass中也“算作”某类的子类，必须同时实现__subclasscheck__ - 两者都定义在元类里，但参数不同：
__subclasscheck__(cls, subclass)中subclass是类对象，不是实例
哪些地方容易踩坑？
最隐蔽的问题是：元类一旦被多个类共用，__instancecheck__ 就会作用于所有使用它的类，而不仅仅是你预期的那个。
立即学习“Python免费学习笔记（深入）”；
- 别把业务逻辑硬编码进元类——比如写死检查
instance.role == 'admin'，这会让元类无法复用 - 避免在
__instancecheck__中修改对象状态或触发副作用，它应该纯函数式 - 如果目标类本身已有父类且依赖标准继承行为，覆盖
__instancecheck__可能导致第三方库（如 typing 检查、mypy）误判类型 - CPython 3.12+ 对元类方法调用做了优化，但旧版本中过度嵌套元类可能引发递归或缓存失效
真正难的不是写出来，而是判断“是否真的需要绕过 Python 的类型系统”——多数时候，用协议（typing.Protocol）或显式接口检查更清晰、更易维护。
