Pydantic模型 | 盛溪的博客

slug

type

status

date

在 Python 里，字典（dict）是极其松散的。假设你的前端发来一个 JSON：

感受点： 如果前端少传了字段，或者把 user_id 传成了 "abc"，你的程序会在运行到一半时突然崩掉（抛出 KeyError 或 ValueError）。

用了 Pydantic： 数据在进入你核心逻辑的第一秒就被拦截了。它会自动把字符串 "123" 转成 int，如果数据格式不对，它会直接报错并告诉你具体哪一行、哪个字段有问题，而不是让脏数据污染你的整个系统。

Python 是一门动态语言，这意味着你的 IDE（如 Cursor 或 VS Code）很多时候不知道 data["user_info"]["name"] 到底是什么。

感受点： 当你使用 Pydantic 模型时：

在你做 RAG 或 Agent 的时候，这可能是最让你有感的场景。

你给 Claude 下指令：“请以 JSON 格式返回用户的简历信息。”

没用 Pydantic： LLM 可能会返回 {"name": "Felix"}，也可能返回 {"user_name": "Felix"}。你得写一堆 if-else 去解析。

用了 Pydantic： 你直接定义一个 ResumeModel，然后把 LLM 的字符串丢进去。Pydantic 会帮你校验：如果 LLM 少写了关键字段，或者格式不对，你可以直接捕获异常并让 LLM 重试（Retry），或者直接将其映射为你系统内部标准的 Python 对象。

你可以对比一下这两段代码，想象一下如果你正在处理 50 个字段的简历数据：

方案 A：纯 Dict（手动挡）

方案 B：Pydantic（自动挡）

Pydantic 的本质是：在“不可信的外部数据”和“可信的内部逻辑”之间，筑起了一道坚固的防火墙。