pydantic v2 中 model_validate 失败应通过封装校验函数 + try/except validationerror 兜底，避免在模型方法内处理；必须用 model_validate 替代已弃用的 parse_obj，输入需为原生类型并预处理（如 json.loads、model_dump）；校验失败时通过 validationerror.input（v2.5+）或手动传入原始数据保障审计可追溯。
Pydantic v2 里 model_validate 失败后怎么不崩？
校验失败直接抛 ValidationError 是默认行为，但生产代码里不能让整个请求因为一个字段错就 500。得提前拦截异常，转成可控的返回或日志。
关键不是“捕获异常”，而是明确在哪一层做兜底：在 fastapi 的依赖里？还是封装一层校验函数？推荐后者，更可测、不耦合框架。
- 用
try/except ValidationError包住model_validate，别漏掉from __future__ import annotations（v2.7+ 需要） - 不要在
__init__或model_construct里兜底——它们绕过校验，兜了也没用 - FastAPI 中若用
Body()注入模型，异常会自动转 422，此时兜底要放在中间件或自定义依赖里，而不是模型方法内
用 parse_obj 还是 model_validate？
parse_obj 已在 Pydantic v2 中弃用，v2.6+ 会警告，v3 直接移除。所有新代码必须用 model_validate，它更严格、支持更多上下文（比如 context 参数传校验依赖项）。
旧项目迁移时容易卡在嵌套字典结构上：如果数据是 dict 但含 datetime 字符串，model_validate 默认不自动解析，得配 type_adapter 或加 @field_validator。
立即学习“Python免费学习笔记（深入）”；
-
model_validate要求输入是纯 python 原生类型；JSON 字符串得先json.loads() - 从数据库 ORM 拿到的对象（如 SQLAlchemy model）不能直接喂给
model_validate，得先用model_dump转成 dict - 想保留原始字段名（比如下划线）又想校验驼峰 API 输入？得设
model_config = ConfigDict(alias_generator=to_camel)
校验失败后，怎么保留原始数据做审计？
Pydantic 默认只报错不存原始值，但运维排查时经常要问：“用户到底传了啥？”——不能只靠日志拼接，得在异常对象里直接拿到。
ValidationError 实例有 .input 属性（v2.5+），但它只在特定路径下可用；更稳的方式是手动把原始数据传进校验函数，和异常一起记录。
- 别依赖
e.errors()里的'input'字段——它可能被裁剪或脱敏 - 对敏感字段（如 password、Token），在校验前就做
copy.deepcopy并剔除，再传给日志函数 - 如果用 structlog 或 sentry，把原始数据作为 extra 字段传入，别塞进 message 字符串里（易被截断或注入）
自定义校验器里 raise ValueError 怎么统一兜底？
写 @field_validator 时习惯用 raise ValueError("xxx")，但这样会丢失字段路径信息，错误堆栈也难定位。Pydantic 要求抛 PydanticCustomError 或让 ValidationError 自动包装。
更麻烦的是：自定义逻辑里可能调第三方 API，超时或网络错误怎么办？这些不属于数据格式问题，但用户看到的也是校验失败。
- 网络类异常（如
requests.RequestException）绝不能裸抛，得转成PydanticCustomError(code="external_api_failed", ...) - 避免在 validator 里做重试——校验阶段应幂等、轻量；重试逻辑提到 service 层
- 如果字段校验需查库，务必设 timeout，并在 except 里明确区分 “DB 不可用” 和 “ID 不存在”，前者该告警，后者才是业务校验失败
事情说清了就结束。最常被跳过的其实是错误上下文的保留方式——不是记日志就行，是要让原始输入、校验路径、触发条件三者能对得上。