NamedTuple 比普通 tuple 更适合配置或返回值，因其支持字段名访问、不可变且零开销，但不可赋值，需用 _replace() 修改；适用 API 返回、查询结果等场景，不适用动态修改或需方法的场景。
NamedTuple 为什么比普通 tuple 更适合做配置或返回值
因为 NamedTuple 允许你用名字访问字段，而不是靠位置索引——这直接消除了 my_tuple[2] 这种“猜含义”的风险。它底层仍是不可变 tuple，内存和性能开销几乎为零，但可读性跃升一个量级。
常见误用是把它当类用：比如试图在实例上赋值 obj.field = new_value，会报 AttributeError: can't set attribute。记住：它是不可变的，要改就得用 _replace()。
- 适合场景：API 返回结构（如
requests.get().json()的解析结果）、数据库查询行、函数多返回值封装 - 不适用场景：需要动态增删字段、频繁修改字段值、需继承或添加方法（此时该用
dataclass） - 字段名必须是合法标识符，不能是数字开头或含空格，比如
"2024_status"合法，"2024 status"会报ValueError
如何正确定义并初始化 NamedTuple（避开 _fields 和 _asdict 的陷阱）
定义时推荐用 typing.NamedTuple（Python 3.6+），而不是 collections.namedtuple，前者支持类型注解，IDE 能补全，mypy 也能校验。
from typing import NamedTuple <p>class User(NamedTuple): name: str age: int is_active: bool = True # 支持默认值
初始化时别写成 User(name="alice", age=30, is_active=True) 这种冗余形式——虽然合法，但容易漏字段且无必要。更稳妥的是按顺序传参，或只对有默认值的字段用关键字：
立即学习“Python免费学习笔记（深入）”；
-
User("bob", 25)→is_active自动为True -
User("carol", 28, is_active=False)→ 混合使用也 OK - 避免用
_fields做运行时判断字段数，它只是元组，不是动态 schema；要用len(obj)或obj._fields（仅调试用） -
_asdict()返回dict，但注意它不是深拷贝，原对象字段若为可变对象（如 list），修改 dict 中对应值会影响原对象
NamedTuple 和 dataclass 在什么情况下该选谁
如果只需要轻量级、不可变、带字段名的容器，NamedTuple 是更优解；一旦出现以下任一需求，就该切到 @dataclass：
- 需要可变字段（比如后续要
user.age += 1） - 想加自定义方法（如
def is_adult(self): return self.age >= 18） - 字段类型复杂，比如嵌套
Optional[List[str]]，NamedTuple对某些泛型支持较弱（尤其 Python < 3.9） - 要序列化成 JSON 且希望忽略某些字段，
dataclass配合dataclasses.asdict()更可控
两者都能用 __annotations__ 查字段类型，但 NamedTuple 的类型信息在运行时可能被擦除（取决于 Python 版本），而 dataclass 更稳定。
Pydantic BaseModel 不是 NamedTuple 的替代品，而是另一条路
如果你在做 API 输入验证、字段转换（比如把字符串 "2024-01-01" 自动转成 date）、或需要严格的数据契约，pydantic.BaseModel 才是正解。它会主动校验、抛错、提供 .model_dump() 等方法。
NamedTuple 不做任何运行时检查：传个 age="thirty" 它照收不误，类型注解只对静态分析工具生效。
- 典型错误：用
NamedTuple接收用户输入（如 form data），结果后期发现字段类型错乱却无提示 - 正确做法：前端/外部数据 →
BaseModel实例化校验 → 内部逻辑用NamedTuple或dataclass处理 - 性能上，
NamedTuple初始化最快，BaseModel有验证开销，别在高频循环里滥用
字段命名冲突、默认值覆盖、类型擦除这些细节，往往在重构时才暴露出来——写的时候省事，读的时候费劲。NamedTuple 的好处得靠写得规范才能兑现。
