pydantic v2 的 rust 核心需正确调用 api 才能发挥性能优势：用 model_validate 替代 parse_obj、批量校验优先 typeadapter、启用 strict=true 跳过类型转换、慎用 extra="forbid"，否则性能与 v1 相当。
Pydantic v2 的 Rust 核心不会自动生效——必须用对 API、避开默认陷阱，否则性能和 v1 差不多。
用 model_validate 替代 parse_obj
这是最常见也最容易忽略的提速点。v2 保留了 parse_obj 仅作兼容，它仍走旧的 Python 校验路径；而 model_validate 才真正调用 pydantic-core 的 Rust 引擎。
- ❌ 错误写法：
UserModel.parse_obj(data)—— 即使装了 v2，也慢 - ✅ 正确写法：
UserModel.model_validate(data)—— 实测快 1.5–2.8 倍 -
model_validate不接受**kwargs形式传参，必须传dict或对象，否则直接抛ValidationError - 如果数据来自 JSON 字符串，优先用
model_validate_json()，比先json.loads()再model_validate()少一次 Python 层解析
批量校验别逐行 BaseModel(**row)，改用 TypeAdapter
逐行实例化 BaseModel 会反复构造验证逻辑、重复生成 schema，Rust 引擎的优势被完全抵消。而 TypeAdapter 是为“同构批量数据”设计的，一次编译、多次复用。
- ✅ 正确姿势：
adapter = TypeAdapter(list[OrderRow]); adapter.validate_python(csv_rows) - ⚠️ 别滥用：单次只校验 1–2 条时，
TypeAdapter初始化开销反而更高 -
TypeAdapter不支持model_config配置项（如str_strip_whitespace），这些必须写死在模型定义里 - 字段级自定义校验器（如
@field_validator）若用 Python 实现，会跳出 Rust 路径——复杂逻辑尽量用内置约束（gt,pattern等）替代
开启 strict=True 跳过类型转换，但得确保上游数据干净
strict=True 不是“开关”，而是让校验器跳过所有隐式转换（比如不把 "123" 转 int），直接做内存位匹配，省掉大量运行时判断。
- 启用后
model_validate耗时再降 20–30% - 配置方式：
model_config = ConfigDict(strict=True) - 风险：前端传
{"age": "25"}会直接失败，不是警告；Union[int, str]输入字符串也不会 fallback - 适用场景：内部服务调用、JSON Schema 已约束字段类型、CSV/DB 导入等可控输入源
别碰 extra="forbid"，除非真需要强契约
v2 默认允许未知字段（兼容 v1），但设 extra="forbid" 会触发额外字段扫描，增加 CPU 开销，实测性能降约 15%。
- 字段越多、输入越杂，性能回落越明显；简单模型（≤5 字段）几乎无感
- 建议仅在 OpenAPI 明确字段契约的接口中开启；日常内部流转用
extra="ignore"更稳 - 如果确认数据可信（如 DB 查询结果），可用
model_construct()完全绕过校验，纯构造对象——它不走任何 Rust 或 Python 校验逻辑
真正卡住性能的往往不是 Rust 引擎本身，而是你在每个请求里重复创建 TypeAdapter、或对单条数据硬套批量接口——这些细节不调，再快的引擎也白搭。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
