用Pydantic.BaseModel校验最省心，但需避开默认值陷阱：字符串为空须用Optional[str] + default=None；数值范围校验须用Field(ge=le)；错误信息应通过e.errors()结构化提取；轻量场景可选dataclasses+typeguard。
用 pydantic.BaseModel 做校验最省心，但得避开字段默认值陷阱
绝大多数 Python 项目里，校验不是写一堆 if isinstance(x, str)，而是靠结构化定义驱动。用 pydantic.BaseModel 是当前最通用的选择，它把类型声明、非空约束、长度限制全收进类定义里，自动触发校验。
常见错误现象：ValidationError 报错位置反直觉，比如字段没传却提示“field required”，其实是字段没设 default=None 或 Optional；或者用了 Field(default="")，结果空字符串被当成有效值通过，但业务上其实要拒绝。
- 字符串字段想允许为空？必须显式写
Optional[str]+default=None，光写str = None会报类型错误 - 数值范围校验别只靠注解，用
Field(ge=0, le=100)，否则int注解本身不检查大小 - 嵌套模型校验是递归的，但
model_dump()默认不包含未通过校验的字段——这点容易误以为数据丢了
校验失败时怎么拿到清晰错误信息，而不是一长串 ValidationError
直接 print(e) 出来的错误堆栈对调试没用，真正要的是字段名、错误类型、原始值这三项。Pydantic v2 提供了 e.errors() 方法，返回结构化列表，每个元素带 loc（字段路径）、msg（提示）、input（出问题的原始值）。
- 别用
str(e)解析错误，它格式不稳定，v1/v2 差异大 - 想转成 JSON 返回给前端？用
[{"field": ".".join(err["loc"]), "msg": err["msg"]} for err in e.errors()] - 自定义错误消息？在
Field里加description不起作用，得用validation_alias配合json_schema_extra，或者重写__init__捕获异常再包装
需要轻量级校验时，别硬套 Pydantic —— dataclasses + typeguard 更合适
如果只是函数入参校验，又不想引入 Pydantic 的模型生命周期（如 model_validate、model_dump），用 @typechecked 装饰器配合 dataclass 更干净。它不改数据结构，只做运行时类型断言，启动快、无额外对象开销。
立即学习“Python免费学习笔记（深入）”；
-
typeguard对Union和Literal支持好，但对嵌套dict的键名不做校验——它只管类型，不管业务规则 - 和 Pydantic 混用要注意：Pydantic 模型实例不能直接传给
@typechecked函数，会因类型不匹配报错，得先用.model_dump() - 性能敏感场景（如高频 API 入口），
typeguard比 Pydantic 快约 3–5 倍，因为跳过了模型初始化和字段解析
自定义校验逻辑绕不开 @field_validator，但得注意执行顺序和上下文
业务规则往往超出了类型+范围，比如“结束时间必须晚于开始时间”。这时候必须写自定义校验器，而 Pydantic v2 的 @field_validator 是唯一正路。但它不是独立运行的——它依赖字段已通过基础类型校验，且多个校验器按装饰顺序执行。
- 跨字段校验（如比较两个时间）必须用
@model_validator(mode="after")，@field_validator拿不到其他字段值 - 校验器里抛
ValueError会被自动转成标准错误，但抛TypeError会中断整个流程，别乱用 - 异步校验不支持——Pydantic 同步模型里不能
await，要查数据库就得提前把结果塞进context传进来
default_factory，又配了 @field_validator，还参与 @model_validator，执行链就很容易漏掉某环。上线前务必用边界数据（空、None、超长、非法字符）跑一遍真实调用路径。 
