isinstance 是 Python 类型检查的事实标准，因 type() 在继承、ABC 和第三方类型适配中失效；isinstance 支持 MRO 查找、抽象基类和多类型元组，而 type() 仅比较精确类对象，仅在需严格区分类型身份时才适用。
isinstance 是 Python 类型检查的事实标准，绝大多数场景下应直接用它替代 type() —— 不是因为它“更高级”，而是因为 type() 在继承、抽象基类、第三方类型适配等常见需求上会直接失效。
子类实例被 type() 当成“陌生人”
当你写 type(obj) is list，它只对原生 list 实例返回 True；一旦 obj 是 collections.UserList 子类、array.array（若继承自 list）、甚至某些 ORM 的查询集，结果就是 False，哪怕它支持所有 .append()、[0]、for x in ... 操作。
这是因为 type() 只读对象的 __class__ 属性，不查 MRO 链。而 isinstance(obj, list) 会顺着继承链向上找，只要 obj 属于 list 或其任意子类，就通过。
- 常见错误现象：
type(data) is dict对types.MappingProxyType或requests.cookies.RequestsCookieJar返回False - 后果：API 参数校验失败、序列化逻辑跳过、调试时误判“类型不对”
isinstance 能识别抽象基类（ABC），type() 根本不认
Python 的 collections.abc.Sequence、numbers.Real、typing.Iterable 等不是用来实例化的，而是定义“能力契约”的接口。你不能写 type([1,2,3]) is collections.abc.Sequence —— 它会直接抛 TypeError，因为 type() 第二个参数必须是具体类。
立即学习“Python免费学习笔记（深入）”；
而 isinstance([1,2,3], collections.abc.Sequence) 返回 True，且同样兼容 pandas.Series、numpy.ndarray（若实现相应协议）等第三方类型。
- 使用场景：写一个通用数据处理器，想支持所有“能迭代+能索引”的对象，用
isinstance(data, (collections.abc.Sequence, collections.abc.Iterator)) - 容易踩的坑：传
list给只接受collections.abc.MutableSequence的函数时，type()判断毫无意义
多个类型判断必须用元组，type() 不支持这种表达
检查一个值是不是数字？正确写法是 isinstance(x, (int, float, decimal.Decimal))。这是一次调用、语义清晰、性能稳定。
type() 没有等价写法：传 list 或 set 给它会报 TypeError: isinstance() arg 2 must be a type or tuple of types；用 or 连接多个 type() 表达式不仅啰嗦，还容易漏掉类型、破坏短路逻辑。
- 参数差异：
classinfo参数只接受单个类型或类型元组，不接受其他序列 - 性能影响：循环里反复用
type(x) == int or type(x) == float比单次isinstance(x, (int, float))多两次函数调用和两次比较
type() 唯一合理的用途：你真正在意“谁生的它”
极少数场景需要排除所有子类，比如：
- JSON 序列化要求严格原生
int，拒绝numpy.int64或decimal.Decimal - 调试时确认某个变量是否被意外 monkey-patch 成子类实例
- 写类型系统底层工具（如 mypy 插件、AST 分析器），需精确区分类型身份
此时才用 type(x) is int 或 type(obj) is MyModel。但要注意：跨模块导入时，MyModel 类对象可能因路径不同导致 is 判断失败，这时反而要回退到字符串形式的 isinstance(obj, "MyModel")（Python 3.10+）。
真正难处理的从来不是“怎么写”，而是“为什么这里必须用 type() 而不是 isinstance()”——多数人连这个前提都没想清楚，就先写了 type()。
