校验逻辑不该写在业务函数里，因其违背单一职责、导致重复代码、错误响应不准确、浪费计算资源且阻碍监控审计；应统一收口至边界层，如FastAPI+Pydantic在反序列化后、业务前强制校验，确保契约可执行。
为什么校验逻辑不该写在业务函数里
因为业务函数的核心职责是处理「正确输入」下的领域逻辑，一旦混入校验，就变成既要判断对错、又要执行动作，违背单一职责。更实际的问题是：同一个数据结构可能被多个业务函数使用，重复写 if not isinstance(data, dict) 或 if 'id' not in data 会让代码散落、难维护、易漏检。
常见错误现象：KeyError 直接抛到上层、TypeError 在业务中间才暴露、API 返回 500 而不是 400 —— 这些都不是业务该兜的底。
- 校验提前失败，能避免无效计算（比如对空列表调用
sum()前先确认非空） - 边界层统一收口后，日志、监控、审计点更集中，比如所有缺失
user_id的请求都能被同一段规则捕获 - 业务函数签名更干净，比如
def create_order(items: List[Item], user_id: int) -> Order:，类型注解本身就能被静态检查工具利用
FastAPI 和 Pydantic 是怎么把校验“推到边界”的
它们不是靠文档或约定，而是靠运行时强制：请求进来的 JSON 被自动解析成 BaseModel 实例前，Pydantic 就已按字段声明完成类型转换 + 约束校验；失败则直接返回 422，并附带清晰的 detail 字段。这本质是把「数据契约」从注释/文档变成了可执行的接口契约。
关键点在于：校验发生在反序列化之后、业务逻辑之前，且不可绕过。
立即学习“Python免费学习笔记（深入）”；
-
Field(...)表示必填，Field(default=None)表示可选，区别于 Python 默认参数语义 -
constr(min_length=1)比手写if len(name) == 0:更可靠，它同时约束 JSON 解析阶段和模型实例化阶段 - 注意
validate_assignment=True仅影响模型属性赋值，不影响 API 入参校验，别误以为开了它就能替代路由层校验
手写校验器时容易忽略的兼容性陷阱
自己写 validate_request() 函数看似灵活，但很容易在边界场景翻车：比如前端传了字符串 "true"，而你只检查 data.get('is_active') is True；或者用了 datetime.fromisoformat() 却没处理 UTC 偏移，导致 2024-01-01T12:00:00+08:00 报错。
这些不是逻辑 bug，是类型契约模糊带来的必然结果。
- 不要依赖
type(x) is str，改用isinstance(x, str)（支持子类） - 数值校验慎用
float(x)，它会把"inf"、"nan"也转成功，而多数业务不需要这种值 - 嵌套结构校验要递归，但别手动写递归——用
pydantic.parse_obj_as()或model_validate()（v2）更稳
什么时候真得把校验往里挪一层？
极少数情况：当某个字段的合法性必须依赖数据库状态，比如「订单所属用户是否已被冻结」，这时不能靠 Pydantic 静态规则判断，得查库。但它依然不该出现在核心业务函数里，而应放在一个独立的 check_user_status(user_id: int) 边界辅助函数中，并由路由 handler 显式调用。
真正危险的是：把这类检查藏在 create_order() 内部，导致单元测试无法隔离验证、事务边界混乱、甚至出现 N+1 查询。
- 数据库依赖型校验 = 必须 IO，必须异步或同步显式发起，不能假装它是纯逻辑
- 这类检查的结果通常要参与决策分支（如拒绝创建），所以它的失败应该映射为明确的异常类型（如
UserFrozenError），而不是泛化成ValueError - 如果多个接口都要查用户状态，把它抽成依赖注入的服务，别复制粘贴 SQL
校验的位置不是凭经验拍的，是看它是否依赖外部状态、是否可缓存、是否影响并发安全——这些细节一旦模糊，边界就会坍塌。
