FastAPI 是什么？它为什么性能比较好？

简化版

FastAPI 是一个基于 Python 类型注解构建 Web API 的现代框架，底层依赖 Starlette 处理 Web 能力，依赖 Pydantic 做数据校验和序列化。它性能较好，主要因为运行在 ASGI 生态上，天然支持异步 I/O，同时框架本身的请求处理链比较轻量。

详细版

FastAPI 的核心特点可以从三层理解：

Web 层：FastAPI 基于 Starlette，提供路由、中间件、请求响应、WebSocket、后台任务等能力。
数据层：FastAPI 借助 Pydantic，根据类型注解自动完成请求参数校验、响应模型序列化和错误信息生成。
文档层：FastAPI 会根据路由、类型注解和模型自动生成 OpenAPI 文档，并提供 Swagger UI / ReDoc。

它性能较好的原因不是“用了异步就一定快”，而是：

ASGI 支持高并发连接和异步 I/O；
Starlette 本身比较轻量；
类型注解让参数解析和文档生成更清晰，减少手写胶水代码；
对 I/O 密集型接口，例如数据库、HTTP 调用、Redis 访问，异步模型可以减少线程等待。

面试中要注意：FastAPI 并不会让 CPU 密集型任务自动变快。如果接口主要做大计算，仍然会阻塞事件循环，需要放到进程池、任务队列或专门的计算服务中。

完整版教学

一、FastAPI 解决的核心问题是什么

传统 Python Web API 项目里，开发者经常需要重复写很多“胶水代码”：从请求里取参数、判断参数类型、检查字段是否为空、把对象转成 JSON、维护接口文档、处理校验错误。项目一大，这些重复逻辑会变成维护负担。

FastAPI 的设计思路是：既然 Python 已经有类型注解，那就让类型注解成为 API 的契约。比如：

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class UserCreate(BaseModel):
    name: str
    age: int

@app.post("/users")
async def create_user(user: UserCreate):
    return {"name": user.name, "age": user.age}

这里的 UserCreate 不只是普通类，它同时承担了请求体结构说明、字段类型校验、错误提示生成和 OpenAPI 文档描述。开发者不用再手动判断 age 是否是整数，也不用单独维护一份接口文档。

这就是 FastAPI 很受欢迎的根本原因：它把“代码、校验、文档”尽量统一到同一套类型声明里。

二、FastAPI 的底层组成

FastAPI 自身更像一个整合层，真正支撑它的有两个重要组件。

第一个是 Starlette。Starlette 是轻量级 ASGI Web 框架，提供路由、请求响应对象、中间件、异常处理、WebSocket、后台任务等基础能力。FastAPI 的很多 Web 能力都来自 Starlette。

第二个是 Pydantic。Pydantic 负责基于类型注解进行数据校验、类型转换、模型序列化和错误信息组织。FastAPI 的请求体验、响应模型和自动文档，很大程度依赖 Pydantic。

可以这样理解：

FastAPI = Starlette 的 Web 能力 + Pydantic 的数据能力 + 自动 OpenAPI 文档 + 依赖注入等增强能力

所以面试时不要把 FastAPI 说成一个“凭空实现所有能力”的框架。更准确的表述是：FastAPI 站在 ASGI、Starlette 和 Pydantic 之上，提供了一套面向 API 开发的高效封装。

三、为什么 FastAPI 性能比较好

FastAPI 性能较好，首先来自 ASGI 模型。传统 WSGI 是同步接口规范，典型场景下一个请求会占用一个工作线程或进程，遇到数据库、网络请求这类 I/O 等待时，线程可能大部分时间都在阻塞。

ASGI 支持异步调用。一个请求在等待数据库或远程接口返回时，可以把执行权交还给事件循环，让同一个线程继续处理其他请求。这对 I/O 密集型系统非常有帮助。

第二个原因是 Starlette 本身轻量。FastAPI 不像某些全家桶框架那样默认加载大量组件，路由和中间件链路比较直接。

第三个原因是类型声明减少了运行时分散处理逻辑。参数校验、序列化、文档生成都围绕模型组织，代码路径更清晰，也减少了业务层里的重复判断。

但是要把“性能好”讲得准确：FastAPI 不是魔法。异步提升的是 I/O 并发能力，不是单个 CPU 计算任务的执行速度。

四、FastAPI 适合什么场景

FastAPI 特别适合构建 RESTful API、微服务接口、机器学习模型服务、内部管理接口、网关层轻量服务，以及需要自动文档的前后端协作项目。

比如一个 AI 推理平台的后端，可能要提供模型调用接口、任务查询接口、文件上传接口、健康检查接口。FastAPI 的类型校验和自动文档可以让接口契约很清楚，异步能力也适合处理大量外部服务调用。

它不一定适合所有场景。如果项目是强后台管理系统，内置 ORM、Admin、权限、模板生态都很重要，Django 可能更省事。如果团队对异步编程没有经验，滥用 async 也可能带来隐藏问题。

五、常见误区与追问

追问角度	合格回答	容易失分的说法
性能来源	ASGI、Starlette 轻量链路、异步 I/O、Pydantic 契约化共同作用	只说 FastAPI 用了 async 所以一定快
框架定位	面向 API 的现代 Web 框架，整合 Starlette、Pydantic、OpenAPI	把 FastAPI 说成全家桶或 ORM 框架
适用场景	API、微服务、模型服务、前后端分离项目较合适	所有 Python Web 项目都无脑选 FastAPI

请求进入
  -> Starlette/ASGI 处理 Web 链路
  -> FastAPI 解析路由和依赖
  -> Pydantic 校验输入 / 序列化输出
  -> OpenAPI 同步生成接口契约

记忆钩子：FastAPI 的“快”主要是 I/O 并发和框架链路轻，不是让 CPU 计算凭空变快。

第一个误区是认为 FastAPI 一定比 Flask、Django 快。框架基准测试只能说明框架层开销，真实项目性能往往由数据库查询、缓存策略、网络调用、序列化成本和部署参数决定。

第二个误区是所有接口都写 async def。如果函数内部调用的是同步数据库驱动或同步 HTTP 客户端，写成 async def 不但不能获得异步收益，还可能阻塞事件循环。

第三个误区是把自动文档当成最终文档。OpenAPI 文档能描述接口结构，但业务语义、错误码约定、权限说明、幂等规则仍然需要认真维护。

误区：FastAPI 一定比 Flask、Django 快。 基准测试通常测的是框架层开销，真实系统常被数据库、外部 HTTP、缓存命中率、JSON 序列化和部署参数限制。
误区：用了 FastAPI 就等于全链路异步。 只有数据库驱动、HTTP 客户端、Redis 客户端等 I/O 组件也支持异步，并且代码正确 await，异步模型才有收益。
误区：自动文档可以替代接口设计。 OpenAPI 能生成参数和 schema，但错误码、权限规则、幂等语义、分页约定仍要人为设计。
追问：FastAPI 和 Starlette、Pydantic 是什么关系？ Starlette 提供 ASGI Web 能力，Pydantic 提供数据校验和序列化，FastAPI 把它们整合成面向 API 开发的框架体验。
追问：CPU 密集型任务适合直接放在 FastAPI 路由里吗？ 不适合长时间占用事件循环或 worker；图像处理、模型推理、复杂加密这类任务通常要放到进程池、任务队列或独立推理服务。
追问：如果 100 个请求都在等外部接口 200ms，异步有什么价值？ 异步可以在等待外部 I/O 时释放事件循环去调度其他请求，提高吞吐和资源利用率；单个外部接口本身的 200ms 延迟不会被 async 消除。

六、面试表达的边界和取舍

回答“FastAPI 是什么”时，最好不要只堆优点，还要能讲清楚选择边界。面试官通常想确认你是否知道框架优势来自哪里，也是否知道它解决不了什么。

项目特征	更倾向 FastAPI	需要谨慎
API 契约	前后端分离、OpenAPI 文档重要	只是少量内部脚本接口
I/O 模型	外部 HTTP、数据库、缓存调用多	主要是 CPU 计算且没有任务隔离
团队经验	熟悉类型注解、Pydantic、异步 I/O	团队误用 async 或缺少部署经验

例如一个接口平均有 3 次外部 I/O，每次约 100ms，异步可以让等待期间的 worker 继续处理其他请求；但如果接口要连续做 500ms CPU 计算，异步本身不会让这 500ms 消失。面试时把这个边界说出来，比单纯说“性能好”更可信。

七、加强记忆

记 FastAPI，要抓住“类型注解驱动 API 开发”这条主线：Starlette 负责 Web，Pydantic 负责数据，ASGI 支持异步并发，OpenAPI 自动生成文档。性能优势主要体现在 I/O 密集型高并发场景，CPU 密集型任务仍然要靠进程、任务队列或专门服务处理。

简化版

详细版