Pydantic是Python数据校验首选，将类型、默认值、约束和错误提示统一于BaseModel；dataclass+__post_init__适合轻量校验；jsonschema适用于跨语言协议对齐；校验需关注时机与位置，避免错位。
用 pydantic 做结构化数据校验最省力
多数场景下，pydantic 是 Python 中数据校验的首选——它把类型声明、默认值、约束条件和错误提示全收进一个 BaseModel 定义里，校验失败直接抛 ValidationError，不用手写一堆 if isinstance(...) 或正则判断。
常见错误是把校验逻辑混在业务函数里，导致函数职责膨胀、测试难覆盖。正确做法是先过 pydantic 模型，再进业务逻辑：
-
email: EmailStr自动检查邮箱格式，比手写正则更可靠 -
age: int = Field(ge=0, le=150)限制整数范围，ge/le比gt/lt更符合“年龄≥0”的语义 - 嵌套模型支持递归校验，比如
address: Address会自动触发Address的字段检查 - 注意：
pydanticv2 默认不接受额外字段（extra="forbid"），传入未定义 key 会报错，调试时容易卡在这儿
轻量级校验用 dataclasses + __post_init__
当不需要完整模型序列化能力，只想要初始化时做几项关键检查（比如必填字段非空、URL 可解析），dataclass 配合 __post_init__ 更轻快，无第三方依赖。
典型使用场景是配置类或内部 DTO 对象：
立即学习“Python免费学习笔记（深入）”；
- 在
__post_init__里手动 raiseValueError，错误信息可定制，但不会自动聚合多个错误 - 不能像
pydantic那样返回结构化错误详情，适合错误类型单一、开发自用的模块 - 若字段含
Optional，需显式判is None，None不会触发类型检查（dataclass不做运行时类型校验） - 性能略高，但少掉约束 DSL 和 JSON Schema 导出等增值功能
jsonschema 校验适用于外部输入协议对齐
当你对接 OpenAPI、接收第三方 Webhook 或需要与非 Python 系统共用一套 schema 规则时，jsonschema 是事实标准。它不绑定语言，schema 本身是 JSON，可复用、可验证、可文档化。
实操要点：
- 用
validate(instance, schema)校验数据，失败抛ValidationError，但错误信息是纯文本，不如pydantic的字段路径清晰 - 复杂约束（如“若 status=active，则 require deadline”）得靠
if-then-else或dependentSchemas，写起来比 Python 代码啰嗦 - 校验前必须确保输入是 JSON 兼容类型（
datetime得先转字符串），否则jsonschema会直接报类型错误 - 不处理 Python 特有类型（
Path、UUID、自定义类），纯面向序列化后的数据
别忽略校验位置和时机选择
校验不是越早越好，也不是越严越好。真正容易出问题的是校验点错位：
- 数据库写入前做校验？可能漏掉 ORM 层的隐式转换（比如
DateTime字段被自动补时区） - API 入口统一校验？要小心 multipart 表单中文件字段无法被
pydantic直接解析，得提前提取 - 异步任务参数校验？若用
celery，建议在 task 函数开头立刻实例化模型，别拖到中间步骤 - 最隐蔽的坑：校验通过后，数据被其他代码 mutate（比如字典原地修改），后续逻辑拿到的是“已污染”对象——校验只管入口，不管生命周期
