569 字
1 分钟
FastAPIfastapi
FastAPI 参数校验:Query、Path、Body、Cookie、Header

把 Query、Path、Body、Cookie、Header 统一进一个心智模型:参数从哪里来,以及怎样利用 Annotated 和 Pydantic 做精细校验。

官方教程在这里会连续切出 QueryPathBodyCookieHeader 好几页,第一次读容易觉得"怎么又来一个函数"。更顺的理解方式是:它们其实都在回答同一个问题,只是参数来源不同。

1. QueryPathBody 的真正作用#

Python3 点击展开代码
14 lines 展开代码

这里 Query(...) 做了两件事:

  • 告诉 FastAPI:这个参数来自查询字符串
  • 顺手附带额外约束和文档信息

Path()Body() 也是同样的模式,只是来源不同。

2. Annotated 的意义#

Python3 代码示例
1 lines

可以把它拆成两层:

  • 真正的数据类型是 str | None
  • 额外的校验规则和来源说明放在 Query(...)

这样"类型"和"元信息"就放在了一起,读起来会比老写法更清楚。

3. 常见约束:长度、范围、别名、弃用#

QueryPathBody 支持一大批相似的约束参数:

  • max_length
  • min_length
  • pattern
  • gt / ge
  • lt / le
  • alias
  • deprecated
  • include_in_schema
Python3 点击展开代码
9 lines 展开代码

这里:

  • item_id 必须大于等于 1
  • 对外暴露的查询参数名是 item-query

4. 自定义校验:AfterValidator#

有些规则不是 gtmax_length 这种现成参数能覆盖的,这时可以接 Pydantic 验证器。

Python3 点击展开代码
25 lines 展开代码

这一步很重要,因为它说明 FastAPI 并不只支持"表面上的参数约束",而是可以自然接入 Pydantic 更细的校验能力。

5. 用模型承接一整组查询参数#

查询参数一多,散着写会越来越乱。这个时候可以把它们建成一个模型:

Python3 点击展开代码
17 lines 展开代码

这段非常值得记,因为它把"查询参数"也推进了结构化建模这一层。

它们看起来像两个新知识点,本质上还是同一个问题:参数从哪里来。

Python3 点击展开代码
14 lines 展开代码

这类来源参数也能继续用模型收起来:

Python3 点击展开代码
14 lines 展开代码

7. 到这里最值得留下来的心智#

这一层最重要的不是把 Query / Path / Body / Cookie / Header 分别背下来,而是先把统一模式站稳:

  • 参数先有类型
  • 参数再有来源
  • 参数还可以继续叠加规则

后面你再看表单、文件上传、依赖注入,理解会快很多,因为底层模式其实没变。

专题阅读

FastAPI

这篇文章属于同一条阅读链。你可以直接在这里切换,不用再回到列表页重新找。

当前进度5 / 11

留言区

留言

欢迎纠错、补充、交流。昵称和评论内容必填;如果你愿意,也可以留下联系方式,仅站主可见。

0

正在加载评论...

0 / 2000

阅读导航

文章目录

当前阅读位置将在这里显示

0 节