isinstance能正确识别子类实例和抽象基类，type只认精确类型；前者用于能力契约判断，后者仅适用于极少数需排除子类的场景。
isinstance 能正确识别子类实例，type 不能
当你有一个 Dog 类继承自 Animal，然后创建 d = Dog()，isinstance(d, Animal) 返回 True，而 type(d) == Animal 或 type(d) is Animal 都是 False。这是因为 isinstance() 会沿着 MRO 向上查找类型链，type() 只看对象的「亲生父亲」——也就是 Dog 本身。
常见错误现象：
-
type(x) == list在collections.UserList子类上返回 False，哪怕它支持所有列表操作 -
type(data) is dict对types.MappingProxyType或自定义映射类完全失效 - 用
type(obj) is MyModel判断 Django 模型实例，跨模块导入时因类对象身份不一致而偶然失败
isinstance 支持抽象基类（ABC），type 完全不认
Python 的 collections.abc.Sequence、numbers.Real 这类抽象基类不是用来实例化的，而是用来声明「接口能力」的。isinstance([1,2,3], collections.abc.Sequence) 返回 True，但 type([1,2,3]) is collections.abc.Sequence 会直接报错——因为 type() 只接受具体类，根本无法处理 ABC。
这意味着：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 用
isinstance(data, collections.abc.Mapping)能同时兼容dict、OrderedDict、types.MappingProxyType，甚至第三方库实现的映射类 -
type()在这种场景下既不可用，也不可扩展 - 第三方库（如
pandas、numpy）大量依赖 ABC 做类型适配，绕过isinstance()就等于放弃兼容性
检查多个类型时，isinstance 用元组更简洁安全
想判断一个值是不是数字，应该写 isinstance(x, (int, float, decimal.Decimal))，而不是 isinstance(x, int) or isinstance(x, float) or isinstance(x, decimal.Decimal)。
原因很实际：
- 元组写法是单次调用，语义清晰，性能略优（尤其在循环里）
-
classinfo参数只接受元组，传list或set会触发TypeError: isinstance() arg 2 must be a type or tuple of types - 元组中可以混用具体类、ABC、甚至字符串（如
"MyClass"解决前向引用），type()完全不支持这种表达力
type 的唯一合理用途：你明确要排除所有子类
极少数场景下，你真的需要「必须是原生 int，不能是 numpy.int64 或 decimal.Decimal」——比如序列化到 JSON 时强制要求 CPython 原生整数，或调试类型污染问题。这时才用 type(x) is int。
但要注意：
-
type(x) == int不推荐，因为==比较的是值，而类型对象的相等逻辑可能被重载（虽然标准类型不会） -
type(x) is int看似严格，但一旦涉及多解释器或某些 C 扩展，仍可能因类对象身份不一致出问题 - 绝大多数业务代码里，这种「血统洁癖」毫无必要，反而制造维护负担
真正容易被忽略的是：类型检查本身不是目的，确保对象能「做某件事」才是。而 isinstance() 判断的是能力契约，type() 判断的是构造痕迹——Python 的鸭子类型哲学，默认站在前者那边。
