pydantic本身不防sql注入，仅做数据校验；防注入必须依赖参数化查询。它可拦截明显非法输入（如类型错误、超长字段），但无法过滤合法字符串中的恶意逻辑（如' or '1'='1），路径参数更需手动类型转换或白名单校验。
Pydantic 本身不防 SQL 注入，它只做数据校验；真正起作用的是你后续是否用参数化查询。Pydantic 的价值在于帮你把“明显非法输入”挡在业务逻辑外，为参数化查询铺路——但如果你最后还是把 user.name 拼进 SQL 字符串，那所有 Pydantic 校验都等于零。
Pydantic 的 str 字段为什么拦不住注入载荷
攻击者传 ' OR '1'='1 完全符合 str 类型定义，也常满足 min_length 和 max_length。Pydantic 不会主动过滤单引号、分号或 SQL 关键字，它只检查“是不是字符串”，不检查“字符串里有没有恶意逻辑”。
-
username: str默认不做任何内容清洗，Field(min_length=1)对注入无效 - 用
pattern=r'^[a-zA-Z0-9_]+$'做白名单？会直接破坏业务：中文名、邮箱、带空格的搜索词全被拒 - 黑名单正则（如禁止
'或--）极易绕过：/**/UNION/**/SELECT或chr(39)在某些上下文仍可执行
哪些字段约束才真正有用
Pydantic 应聚焦于“结构兜底”和“减少意外路径”，而不是假装能替代数据库层防护。
- 强制类型转换：
user_id: int确保后端拿到整数，避免id=123abc被隐式转成字符串后塞进WHERE id = %s出问题 - 限制数值范围：
page: conint(gt=0, le=1000)防止超大偏移量拖垮查询，间接降低联合注入效率 - 标准化格式：
email: EmailStr或url: AnyHttpUrl让后续参数化查询的值更可预期，减少拼接冲动 - 配合
@field_validator做语义检查：search_keyword截断到 200 字符，避免超长 payload 触发 WAF 误杀或缓冲区异常
Pydantic 校验完的数据必须进参数化查询
校验只是前置动作，执行层才是防线。Pydantic 模型实例若被拼进 SQL 字符串，照样被注入。
- ❌ 危险：
f"SELECT * FROM users WHERE name = '{user.name}'"—— 即使user.name是 Pydantic 实例，照样崩 - ✅ 正确（SQLAlchemy）：
session.execute(text("SELECT * FROM users WHERE name = :name"), {"name": user.name}) - ✅ 正确（ORM）：
select(User).where(User.email == user.email)—— ORM 内部自动参数化 - IN 子句要特别小心：
List[int]不能直接塞进WHERE id IN (?)；得用bindparam("ids", expanding=True)或手动构造等长占位符
最容易被忽略的盲点：路径参数根本不走 Pydantic 校验
像 /user/{id} 这种路径参数，FastAPI 直接当字符串交给路由函数，完全跳过 Pydantic 模型。如果这里不做类型转换或白名单检查，就直接进入数据库操作，风险极高。
- 必须显式转换：
@app.get("/user/{user_id}") async def get_user(user_id: int):—— 利用 FastAPI 的路径参数类型声明做基础转换 - 对动态表名/列名（如多租户切换、排序字段）必须硬校验：
if sort_field not in ["created_at", "name"]:后面直接 raise - 字典或列表存 JSON 字段时，Pydantic 不会自动
json.dumps()，你得手动转字符串再入库
复杂点不在 Pydantic 怎么写，而在你是否清楚每个数据流环节：从路径参数 → 查询参数 → 请求体 → 数据库执行，哪一环漏了类型约束或参数化，哪一环就可能被击穿。最常翻车的地方，永远是“我以为它安全，其实没管”。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
