当调用isinstance(obj, cls)时，Python会检查type(cls)是否定义了__instancecheck__(self, instance)。如果存在，该元类方法决定成员资格，使得在没有继承的情况下能够进行“虚拟子类化”。当实现使用hasattr()或对obj的点属性访问时，会出现危害；如果obj实现了__getattr__或触发isinstance()检查的描述符，元类方法会重新进入，从而导致无限递归。
我们设计了一个验证框架，其中插件需要满足接口而无需显式继承。我们定义了一个Processor ABC，并希望如果plugin暴露一个process方法，isinstance(plugin, Processor)能够成功，从而支持外部库的鸭子类型。
第一种方法要求所有插件要么继承自Processor，要么调用Processor.register()。这种方式类型安全，但对我们的用例不实用；它禁止运行时生成类，并且需要修改第三方代码，而我们无法改变。因此，它无法支持来自不受信任源的动态插件发现。
第二种方法在Processor元类上实现了__instancecheck__，使用hasattr(candidate, 'process')。虽然灵活，但当插件使用属性装饰器通过isinstance验证其返回类型时，就会崩溃，导致RecursionError，因为在第一次调用返回之前，元类方法再次被调用。
我们采用了第三种解决方案：使用object.__getattribute__实现__instancecheck__以绕过描述符逻辑。通过检查type(candidate).__dict__.get('process')并验证其是否可调用，我们避免了触发用户定义的__getattr__或属性副作用。这消除了递归风险，同时保留了动态鸭子类型，使框架能够安全集成数千个异构插件而不需要修改源代码。
class MetaProcessor(type): def __instancecheck__(cls, candidate): # 安全：绕过__getattr__和描述符 try: attr = type(candidate).__dict__.get('process') return callable(attr) except Exception: return False class Processor(metaclass=MetaProcessor): pass
为什么isinstance()查阅第二个参数的元类而不是第一个？
该协议将权力赋予被检查的类型（cls），而不是候选对象（obj）。通过将__instancecheck__放在type(cls)上，Python确保只有类定义控制其成员资格语义。这防止了对象伪装实例检查；类型单方面地定义其实例的构成，保持安全敏感类型检查的完整性。
__instancecheck__和__subclasscheck__之间的关系是什么，为什么它们必须保持一致？
__instancecheck__验证对象是否通过isinstance()，而__subclasscheck__验证类型是否通过issubclass()。如果__instancecheck__接受虚拟实例（未从类继承的对象），__subclasscheck__通常必须接受对应的虚拟子类，以保持不变的条件，即isinstance(obj, cls)意味着issubclass(type(obj), cls)。违反这一点会导致通用容器代码在实例检查通过后检查子类关系时失败。
在__instancecheck__内部使用getattr()如何特别触发无限递归，而不是object.__getattribute__？
getattr(obj, 'name')调用完整的描述符协议，如果属性缺失，可能会调用obj.__getattr__('name')。如果obj.__getattr__实现了延迟加载、日志记录或类型强制转换，而这些操作内部又调用isinstance(obj, OurClass)，则元类__instancecheck__会在返回之前重新进入。相比之下，object.__getattribute__(obj, 'name')（或检查type(obj).__dict__）完全绕过__getattr__和自定义描述符，访问原始实现细节而不触发可能递归的用户代码。