应优先使用 isinstance() 而非 type() 做类型判断，因 isinstance() 遵循 MRO、支持继承与 ABC，体现鸭子类型哲学；type() 仅判别直接类型，适用极少数需严格身份校验的场景。
用 type() 判断类型时，子类实例会“掉链子”
当你写 type(x) == list 或 type(data) is dict，看起来没问题，但只要 x 是 collections.UserList 子类，或 data 是 types.MappingProxyType，结果就是 False——哪怕它支持所有 list/dict 的常用操作。
这是因为 type() 只返回对象的「直接类型」，不走 MRO（方法解析顺序），完全无视继承关系。它适合极少数场景：比如你明确要排除所有子类，只接受「原生 int」而不要 numpy.int64 或自定义数值类。
- 别在条件分支里用
type(obj) is SomeClass做类型分发，容易漏逻辑 -
type()返回的是类对象，不是字符串，所以type(x) == "list"永远是False - 想查对象「到底是谁生的」，
type()有用；想查「它能不能当某种东西用」，它就不行
用 isinstance() 才算真正做「类型兼容性判断」
isinstance() 是 Python 类型检查的事实标准，它按 MRO 向上查找，只要对象属于目标类或其任意祖先类，就返回 True。这意味着 isinstance(my_list, list) 对 UserList、array.array（若继承自 list）、甚至 ABC 实现都可能成立（取决于具体实现）。
它天然适配多态：你写一个函数处理「所有可迭代映射」，用 isinstance(data, collections.abc.Mapping) 就比硬写 type(data) in (dict, OrderedDict, ...) 更健壮、更易扩展。
立即学习“Python免费学习笔记（深入）”；
- 检查多个类型？传元组：
isinstance(x, (int, float)) - 需要解决前向引用（比如类还没定义完就在注解里用）？Python 3.10+ 支持字符串形式：
isinstance(obj, "MyClass")，旧版本别用 - 用 ABC（如
MutableSequence）时，别默认它能调用.append()——接口声明 ≠ 实际实现，运行时仍可能抛NotImplementedError
性能差异几乎可以忽略，但语义差很多
单次调用 isinstance() 和 type() 的开销都在纳秒级，日常代码里完全感知不到差别。真有性能瓶颈的地方，从来不在这里，而在循环体里反复做无谓判断。
真正关键的是语义：用 type() 表达的是「身份认同」（它必须是这个类亲手造的），而 isinstance() 表达的是「能力认可」（它只要符合这个类型契约就行）。Python 的鸭子类型哲学，默认倾向后者。
- 除非你在写类型系统底层、序列化工具或调试器，否则别优先选
type() - 第三方库（如
requests、pandas）大量使用 ABC 和自定义子类，绕过isinstance()很容易导致兼容性断裂 -
isinstance()支持抽象基类，type()不支持——这是决定性的能力边界
容易被忽略的坑：ABC 不等于行为完整
很多人以为 isinstance(x, abc.MutableSequence) 就等于「能安全调用 x.append()」，其实不是。ABC 只保证接口声明，不保证方法实际可调用。比如某个只读实现可能继承了 MutableSequence 但把 append 设为 raise NotImplementedError。
这说明类型检查只是第一道防线，不能替代运行时防御。如果你的逻辑强依赖某个方法，最好加一层 hasattr() 或 try/except。
- 别把
isinstance()当万能胶水，它解决的是「类型归属」，不是「行为保障」 - 对关键操作，尤其是写入类方法，建议组合使用：
isinstance(obj, abc.MutableSequence) and hasattr(obj, "append") - Python 3.12 开始对某些 ABC 的运行时检查更严格，但兼容性逻辑没变——该踩的坑还是得自己踩一遍
