如何判断一个对象是否真的是 tuple 而不是 NamedTuple

应使用 type(obj) is tuple 而非 isinstance(obj, tuple)，因 NamedTuple 等 tuple 子类会使后者误判；type 检查确保仅匹配原生 tuple，避免结构假设错误。

用 type() 而不是 isinstance(..., tuple)

因为 NamedTuple 是 tuple 的子类，isinstance(my_obj, tuple) 对 NamedTuple 实例也返回 True，无法区分。真正判断“是不是原生 tuple”，得看它的**确切类型**：type(my_obj) is tuple。

常见错误现象：写 if isinstance(obj, tuple): ... 后发现 Point(x=1, y=2)（NamedTuple）也被误判为普通 tuple，导致后续按索引取值出错或结构假设崩塌。

• type((1, 2)) is tuple → True
• type(NamedTuple('P', [('x', int), ('y', int)])(1, 2)) is tuple → False
• 注意：不要用 == tuple，必须用 is —— 类型对象是单例，is 更安全、更准确

检查 __class__ 和 __name__ 组合（兼容旧 python 版本）

某些场景下（比如你不能确定对象是否被 monkey patch 过），仅靠 type() is tuple 可能不够鲁棒；这时可退一步，查 obj.__class__ 是否为内置 tuple 类，并确认其 __name__ 是 'tuple'。

使用场景：在做类型敏感的序列扁平化、序列化预处理时，需要严格排除所有自定义 tuple-like 类型（包括 NamedTuple、typing.NamedTuple、dataclasses.make_dataclass 模拟的 tuple 等）。

• obj.__class__ is tuple 和 type(obj) is tuple 效果一致，但前者略显直白
• obj.__class__.__name__ == 'tuple' 不可靠：有人可能动态改名，或遇到 __subclasshook__ 干扰
• 不推荐只看 __name__，容易漏掉用户自定义的 class MyTuple(tuple): ...

为什么 NamedTuple 会干扰判断？它到底是什么

NamedTuple 不是语法糖，而是运行时生成的类，继承自 tuple 并混入字段名和 __new__ 行为。所以它既是 tuple，又是独立类型 —— 这正是类型检查模糊的根源。

性能 / 兼容性影响：直接用 type(x) is tuple 几乎无开销，比反射查 __annotations__ 或 _fields 快得多，且在 Python 3.6–3.12 下行为一致。

• from typing import NamedTuple 定义的类，其 __bases__ 包含 tuple
• collections.namedtuple 生成的类同理，但 __name__ 是你指定的名字，不是 'tuple'
• 别依赖 hasattr(obj, '_fields') 来反向识别 NamedTuple —— 用户可以手动加这个属性

实际校验逻辑建议写法

如果你要写一个“只处理原生 tuple”的函数，最稳妥的守门逻辑就是一行：

if type(obj) is not tuple:     raise TypeError(f"expected tuple, got {type(obj).__name__}")

别试图兼容“看起来像 tuple 的东西”。如果调用方传了 NamedTuple，让它明确报错，比静默处理再出错更容易定位问题。

容易被忽略的地方：tuple 的子类（哪怕只是空继承 class MyTuple(tuple): pass）也会被 isinstance(..., tuple) 放行，但不会通过 type(...) is tuple。这种边界情况在类型严格的工具链（如 Pydantic v2 解析、mypy 插件）里经常暴露出来。