不该用 pydantic 做业务规则判断，它只适合结构化输入的类型与格式兜底；余额是否足够、订单是否取消等依赖外部状态的校验必须交由业务层处理。
Python 输入校验该不该用 pydantic 做业务规则判断
不该。把 pydantic 当成业务校验入口，容易让模型定义膨胀、耦合数据库状态、掩盖真实错误来源。
它适合做「结构化输入的类型与格式兜底」——比如确认 user_id 是整数、email 符合基本格式、created_at 能解析成 datetime。但像「用户余额是否足够支付」「订单是否已被取消」这类依赖外部状态的判断，必须交给业务层。
- 常见错误现象：
ValidationError里混着"余额不足"这类业务提示，导致 API 错误码混乱（HTTP 422 里塞了 400/403 的语义） - 使用场景：FastAPI 的
Request解析、CLI 工具参数解析、配置文件加载 - 性能影响：每次触发
pydantic校验都会新建模型实例，若在循环中校验大量数据，且嵌入了@field_validator调用 DB 查询，会明显拖慢吞吐
if not value: 和 if value is None: 在校验时的区别
前者会把空字符串、0、[]、{} 都判为假；后者只认 None。业务校验里，多数时候你真正想拦截的是缺失值，不是合法的零值或空集合。
比如 discount_rate: float | None 字段，前端传 0 表示“不打折”，传 null 才表示“未填写”。用 if not discount_rate: 会把两种情况一并拒掉。
立即学习“Python免费学习笔记（深入）”；
- 容易踩的坑：用
if not user.phone:判手机号是否存在，结果"0000000000"也被当空处理 - 建议写法：
if user.phone is None:或if not isinstance(user.phone, str) or not user.phone.strip(): - 兼容性注意：Python 3.10+ 可用
match处理多类型可选字段，比嵌套if更清晰
自定义异常该继承 ValueError 还是 Exception
继承 ValueError。它是 Python 内置的语义明确的异常基类，专用于“值不符合预期”的场景，和输入/业务校验强相关。
用 Exception 会导致上层无法精准捕获——比如你想统一处理所有校验失败，写 except ValueError: 就能覆盖 pydantic.ValidationError、int() ValueError、你自己抛的 InvalidAmountError；换成 Exception 就可能误吞 ConnectionError 这类系统异常。
- 实操建议：定义异常时加前缀，如
InvalidEmailError、InsufficientStockError，都继承ValueError - 不要为了“看起来高级”而造新基类，除非你要区分「客户端错」和「服务端错」且有统一中间件处理
- FastAPI 中，继承
ValueError的异常默认映射为 HTTP 422；继承HTTPException才能控制状态码
校验逻辑该放在函数内部还是单独抽成 validate_* 函数
只要校验逻辑超过 3 行，或涉及多个字段交叉判断，就抽成独立函数。否则你会在 create_order() 里看到半屏 if-elif-else，还夹杂着数据库查询和日志。
抽离后的好处不是“代码更整洁”，而是能被单元测试直接 import 调用、能复用到 CLI 或后台任务中、能明确知道「这一块只负责校验，不改状态」。
- 典型交叉校验场景：
start_time和end_time的大小关系、payment_method和currency的组合有效性 - 参数差异：独立函数应接收原始输入（如 dict 或 Pydantic 模型），别传 DB model——校验不该依赖 ORM 实例的懒加载属性
- 容易忽略的一点：抽出来的
validate_*函数，别偷偷修改入参（比如.pop()字段），这会让调用方行为不可预测
边界从来不是由工具划出来的，而是当你在 validate_user_input() 里写下第 2 个 session.query() 时，就已经越过了。
