pydantic-core 从 Python 重写为 Rust 的根本原因是替换整个验证/序列化引擎：V1 纯 Python 实现依赖 isinstance 和动态属性访问，V2 用 Rust 编译为无 GIL 原生模块，支持预编译 CoreSchema、零拷贝序列化、惰性验证及默认禁用 extra 校验，显著提升性能。
pydantic-core 从 Python 重写为 Rust 实现
根本原因不是“优化了 Python 代码”，而是把整个验证/序列化引擎换掉了。V1 的 pydantic-core 是纯 Python 实现，依赖大量 isinstance、动态属性访问和中间 dict 构建；V2 的 pydantic-core 是 Rust 编写的，编译成无 GIL 的原生模块，验证逻辑直接在 Rust 层执行。
这意味着：
- 单字段校验从 V1 的 ~2–3 µs 降到 V2 的 ~0.5–1 µs
- 嵌套模型（如 5 层字典）解析耗时从 3.47s → 1.32s（实测 10 万条）
- 多线程场景下能真正并行——Rust 验证期间释放 GIL，不再被 Python 全局锁卡住
验证器编译 + CoreSchema 缓存
V2 不是每次调用都现场判断类型，而是在模型类首次定义时，就把 int、Field(gt=0)、Annotated[str, AfterValidator(...)] 这些注解“编译”成一棵 Rust 内部的 CoreSchema 树，并缓存在类对象上。
后续所有 model_validate() 调用，都直接走这棵预编译的树，跳过运行时反射和类型推导。V1 则每次都要重新解析类型、构造 validator 对象、递归检查字段。
立即学习“Python免费学习笔记（深入）”；
这个机制带来两个关键影响：
- 首次实例化模型稍慢（编译开销），但后续调用极快
- 带复杂约束（如
constr(regex=r'^[a-z]+$')）的字段，V2 加速比简单str更明显 - 若模型极轻量（仅 2–3 个
str字段），V1 和 V2 差距缩至 10% 以内——编译收益被摊薄
零拷贝序列化与惰性验证
V2 的 model_dump_json() 不再先生成 Python dict 再 json.dumps()，而是 Rust 层直接写出 JSON bytes；model_dump(mode='json') 同样绕过 Python 中间态。
同时，V2 默认启用惰性验证：只有你访问某个字段（比如 obj.name）或显式调用 model_validate()，才触发对应分支校验，不会一上来就全量遍历嵌套结构。
这导致：
- API 响应序列化吞吐量提升 10 倍以上（尤其高频小对象）
- 对部分字段只读、不常访问的场景（如日志记录模型），实际开销远低于 V1
- 开启
validate_assignment=True且高频修改字段时，V2 反而略慢——因为每次赋值都触发完整验证路径
extra="forbid" 默认关闭带来的隐性加速
V2 默认禁用严格模式（即不校验多余字段），而 V1 默认是 extra="ignore" 但实际仍会扫描并丢弃未知键。V2 的默认行为省掉了字段名比对、键过滤等步骤。
如果你手动加 model_config = {"extra": "forbid"}，性能会回落约 15%，因为要额外做键存在性校验。
这个点容易被忽略：很多团队升级后没改配置，却误以为“V2 就是快”，其实真实加速还取决于你是否开启了那些额外校验开关。
