如果你写过 Python Web，大概率从 Flask 或 Django 起步。它们能用，但有两个反复出现的痛点：请求参数要手动校验，接口文档要单独维护。FastAPI 把这两件事在框架层解决了，还顺手把异步写进了骨子里。这篇先把它的定位和技术底座讲清楚，后面几篇再逐个啃路由、数据校验、数据库和部署。
一句话定位
FastAPI 是一个基于 Python 类型注解的异步 Web 框架，专为构建 API 而生。它把「参数校验」「序列化」「自动文档」「异步并发」做成开箱即用的能力，而不是靠第三方插件拼凑。
它不代表「取代 Django」，而是补上了一个长期空缺的位置：用最少的代码写出类型安全、带文档、能扛并发的 API 服务。
技术底座：三块拼图
FastAPI 自己写得很少，它站在三个成熟部件肩上：
| 部件 | 角色 | 解决什么 |
|---|---|---|
| Starlette | ASGI 工具集 | 路由、请求/响应、WebSocket、中间件 |
| Pydantic v2 | 数据校验与序列化 | 用类型注解定义数据模型，自动校验和转换 |
| Uvicorn | ASGI 服务器 | 真正跑异步代码的进程，替代 Gunicorn/WSGI |
关键点在于「类型注解」是这个框架的一等公民。你写的不是给阅读器看的注释，而是框架直接消费的结构：
@app.get("/items/{item_id}") async def read_item(item_id: int, q: str | None = None): return {"item_id": item_id, "q": q}
item_id: int 不是建议，FastAPI 会据此自动把 URL 里的字符串转成 int，转失败直接返回 422 报错。这是 Flask 要装 marshmallow、Django 要装 DRF 才有的能力，FastAPI 原生就有。
为什么叫「现代」：四个硬指标
1. 类型注解驱动
参数解析、校验、OpenAPI 文档、编辑器补全，全部从同一个类型声明推导出来。改一处类型，文档和校验逻辑跟着变，不会出现「代码改了文档没改」的漂移。
2. 原生异步（async/await）
FastAPI 跑在 ASGI 上，路由函数标 async def 就能用 await 处理 IO。一个请求在等数据库或外部 API 时，事件循环去处理别的请求，单机并发量比传统 WSGI（一个请求占一个线程）高一个量级。
3. 自动生成交互式文档
启动后访问 /docs 就是 Swagger UI——你能直接在网页上填参数、点执行、看返回。访问 /redoc 是另一套文档视图。这套 OpenAPI 规范还能直接喂给前端代码生成器（如 openapi-typescript）或 Postman。
4. 接近 Node / Go 的吞吐
FastAPI 的性能基准来自 Starlette，和 Node.js、Go 的同类框架在同一区间，远高于传统同步 Python 框架。注意：这是「框架吞吐」的上限，真实接口速度仍取决于你的数据库查询和业务逻辑。
和 Flask / Django 怎么选
不是谁取代谁，是看你手上的活：
- Flask：轻、自由，但参数校验、文档、ORM 都要自己接。适合极小工具或已有强约定的老项目。
- Django：全家桶，Admin、ORM、认证一条龙，但偏重、异步支持历史包袱重，写纯 API 常显得啰嗦（需要 DRF）。适合带后台管理的内容站。
- FastAPI：API 优先、类型安全、异步原生、文档自动。适合微服务、前后端分离的后端、ML 模型服务。
一句话：要「后台管理系统」选 Django；要「一个干净的 API 服务」选 FastAPI；要「极简脚本」选 Flask。
最小可运行示例
先装依赖（建议用虚拟环境）：
pip install "fastapi[standard]"
standard 额外包含 Uvicorn、Pydantic 等运行所需组件。新建 main.py：
from typing import Union from fastapi import FastAPI app = FastAPI(title="我的第一个 FastAPI", version="0.1.0") @app.get("/") async def root(): return {"msg": "hello"} @app.get("/items/{item_id}") async def read_item(item_id: int, q: Union[str, None] = None): return {"item_id": item_id, "q": q}
启动：
uvicorn main:app --reload --port 8000
打开三处看效果：
http://127.0.0.1:8000/→ 返回 JSONhttp://127.0.0.1:8000/items/42?q=test→item_id是数字 42http://127.0.0.1:8000/docs→ 交互式 API 文档
把 item_id 换成字符串（如 /items/abc）试试，FastAPI 会返回 422 并指明哪段校验失败——你一行校验代码都没写。
它在 AI / ML 圈为什么火
这不是偶然。机器学习服务的典型形态是「输入张量/参数 → 模型推理 → 输出结果」，和 FastAPI 的模式高度契合：
- 模型即函数：用 Pydantic 把输入/输出框成强类型，前端联调不再靠口头约定。
- 并发推理：推理是 IO/计算密集，
async让单进程能同时接多个请求。 - 部署简单：一个 ASGI app 丢进容器就能跑，
/docs让算法同学自己测接口。 - 类型即文档：模型输入输出字段一变，文档自动更新。
Hugging Face、LangChain 等生态大量用 FastAPI 暴露推理端点，就是这个原因。
版本与依赖现状
写这个系列时（2026 年）的稳妥组合：
- Python 3.9+（3.10+ 用
X | None语法更顺手） - FastAPI 0.115.x：稳定主线
- Pydantic v2：Rust 核心重写，校验速度比 v1 快数倍；注意 v1 的某些写法（如
orm_mode）在 v2 改名成from_attributes - Uvicorn 0.30+：生产用
uvicorn或gunicorn -k uvicorn.workers.UvicornWorker
下一篇讲路由与依赖注入——FastAPI 把「参数怎么来」「逻辑怎么复用」设计得比大多数框架都干净，是它最值得学的地方之一。