应使用 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 → Truetype(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 插件）里经常暴露出来。
