数据校验为何放在边界层？

数据校验不应散落在业务函数中，而必须严格收口至边界层（如FastAPI+Pydantic在反序列化后、业务逻辑前强制执行），这不仅践行单一职责、消除重复代码、提升错误响应准确性（返回400而非500），更能避免无效计算、集中监控审计、强化接口契约的可执行性；手写校验易陷兼容性陷阱，而依赖数据库状态的校验虽需后移，也应独立封装为显式、可测试、可注入的边界辅助函数——校验的位置本质是由其是否依赖外部状态、是否可缓存、是否影响并发安全等工程事实决定的，模糊边界将直接导致系统脆弱与失控。

为什么校验逻辑不该写在业务函数里

因为业务函数的核心职责是处理「正确输入」下的领域逻辑，一旦混入校验，就变成既要判断对错、又要执行动作，违背单一职责。更实际的问题是：同一个数据结构可能被多个业务函数使用，重复写 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 字段。这本质是把「数据契约」从注释/文档变成了可执行的接口契约。

关键点在于：校验发生在反序列化之后、业务逻辑之前，且不可绕过。

• 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

校验的位置不是凭经验拍的，是看它是否依赖外部状态、是否可缓存、是否影响并发安全——这些细节一旦模糊，边界就会坍塌。

到这里，我们也就讲完了《数据校验为何放在边界层？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！