当数据结构变得越来越复杂时，单纯依赖列表和字典往往已经不够了。我们既希望表达清晰，又不想一上来就写很多样板代码，这时候 dataclass、NamedTuple 和 TypedDict 就会变得非常有价值。
这一节会围绕“结构化数据应该如何表达”来展开，帮助你理解这三种方案各自的边界、优势和适用场景，让数据表达从“能用”升级为“清楚、稳定、可维护”。
为什么需要结构化数据表达？
假设我们要表示一个用户信息，最随手的写法可能是字典：
user = {"name": "Colin", "age": 28}它当然能用，但随着项目变大，你很快会遇到这些问题：
- 键名靠记忆，不小心就写错；
- 哪些字段必填、哪些可选，不够明确；
- 数据意图不清楚，读代码时上下文成本很高。
所以，结构化数据表达的核心意义，不是替换字典，而是让“这是什么数据、有什么字段、应不应该被修改”这些信息变得更清楚。
dataclass：更轻量的类定义方式
dataclass 很适合表达“以数据为主、行为相对简单”的对象。
from dataclasses import dataclass
@dataclass
class User:
name: str
age: int它会自动帮你生成初始化方法、可读表示、比较等常见样板代码，让你不必手写大量重复内容。
这让 dataclass 成为“比字典更清楚、比手写类更省事”的一个中间解。
默认值与工厂函数
在 dataclass 中，字段可以有默认值：
from dataclasses import dataclass, field
@dataclass
class User:
name: str
tags: list[str] = field(default_factory=list)这里使用 default_factory 的原因，和前面讲函数默认参数时完全一样：避免多个实例共享同一份可变默认值。
这说明很多 Python 设计看似分散，底层思路其实是互通的。
不可变数据类
有些数据对象更适合作为“只读值”来使用，这时可以设置：
@dataclass(frozen=True)
class Point:
x: int
y: int这会让实例更接近值对象语义，有助于减少被意外修改的风险。
所以 dataclass 的一个重要价值，是它既能轻量表达结构，也能按需要逐步增加约束。
NamedTuple：轻量且可读的元组方案
NamedTuple 可以理解成“有字段名的元组”。
from typing import NamedTuple
class User(NamedTuple):
name: str
age: int它保留了元组轻量、不可变、可解包的特征，同时又比裸元组更可读。你不再需要靠位置去猜第一个元素、第二个元素到底代表什么。
它特别适合：
- 字段固定、结构简单的数据；
- 需要保留元组轻量特征；
- 结果主要用于读取，不强调后续修改。
所以如果你面对的是一组稳定且轻量的数据，NamedTuple 往往会比普通字典更可靠，也比完整类定义更省成本。
TypedDict：为字典补充静态约束
有些场景下，数据天然还是字典形态，比如 JSON 载荷、接口返回、动态配置项。这时如果直接换成类，反而不自然。
这时 TypedDict 很有价值：
from typing import TypedDict
class UserPayload(TypedDict):
name: str
age: int它不会改变运行时对象本身还是字典这件事，但会给静态检查工具和编辑器补充结构信息。
所以 TypedDict 的定位非常清楚：保留字典的灵活形态，同时在静态层补上一部分结构约束。
它特别适合：
- 描述接口入参和出参；
- 处理 JSON 数据；
- 临时过渡于动态字典和强结构对象之间。
它们分别适合什么场景？
这三种工具没有绝对谁高级，关键在于你想表达什么。
如果你需要：
- 一个以字段为主的数据对象，并且未来可能附加少量方法，用
dataclass； - 一个非常轻量、不可变、主要用于读取的数据结果，用
NamedTuple； - 一个仍然要保持字典形态，但希望静态工具能理解字段结构的载荷，用
TypedDict。
真正成熟的选择标准，不是“项目里统一只用一种”，而是知道不同数据在约束程度、可变性、语义强度上有不同需求。
总结与预告
这一节我们不再满足于“能装数据”，而是开始追求更清晰、更稳定的数据表达方式。不同的数据结构方案，背后其实对应着不同的约束程度、维护成本和协作效率。
接下来我们会进入 Python 类型标注部分，先从最基础的写法和作用边界开始，看看动态语言为什么同样值得认真对待类型信息。