把 Query、Path、Body、Cookie、Header 统一进一个心智模型:参数从哪里来,以及怎样利用 Annotated 和 Pydantic 做精细校验。
官方教程在这里会连续切出 Query、Path、Body、Cookie、Header 好几页,第一次读容易觉得"怎么又来一个函数"。更顺的理解方式是:它们其实都在回答同一个问题,只是参数来源不同。
1. Query、Path、Body 的真正作用
Python3
点击展开代码
展开代码
这里 Query(...) 做了两件事:
- 告诉 FastAPI:这个参数来自查询字符串
- 顺手附带额外约束和文档信息
Path() 和 Body() 也是同样的模式,只是来源不同。
2. Annotated 的意义
Python3
代码示例
可以把它拆成两层:
- 真正的数据类型是
str | None - 额外的校验规则和来源说明放在
Query(...)
这样"类型"和"元信息"就放在了一起,读起来会比老写法更清楚。
3. 常见约束:长度、范围、别名、弃用
Query、Path、Body 支持一大批相似的约束参数:
max_lengthmin_lengthpatterngt/gelt/lealiasdeprecatedinclude_in_schema
Python3
点击展开代码
展开代码
这里:
item_id必须大于等于 1- 对外暴露的查询参数名是
item-query
4. 自定义校验:AfterValidator
有些规则不是 gt、max_length 这种现成参数能覆盖的,这时可以接 Pydantic 验证器。
Python3
点击展开代码
展开代码
这一步很重要,因为它说明 FastAPI 并不只支持"表面上的参数约束",而是可以自然接入 Pydantic 更细的校验能力。
5. 用模型承接一整组查询参数
查询参数一多,散着写会越来越乱。这个时候可以把它们建成一个模型:
Python3
点击展开代码
展开代码
这段非常值得记,因为它把"查询参数"也推进了结构化建模这一层。
6. Cookie 和 Header 其实还是同一个模式
它们看起来像两个新知识点,本质上还是同一个问题:参数从哪里来。
Python3
点击展开代码
展开代码
这类来源参数也能继续用模型收起来:
Python3
点击展开代码
展开代码
7. 到这里最值得留下来的心智
这一层最重要的不是把 Query / Path / Body / Cookie / Header 分别背下来,而是先把统一模式站稳:
- 参数先有类型
- 参数再有来源
- 参数还可以继续叠加规则
后面你再看表单、文件上传、依赖注入,理解会快很多,因为底层模式其实没变。
专题阅读
FastAPI
这篇文章属于同一条阅读链。你可以直接在这里切换,不用再回到列表页重新找。
部分信息可能已经过时
留言区
留言
欢迎纠错、补充、交流。昵称和评论内容必填;如果你愿意,也可以留下联系方式,仅站主可见。