FastAPI 为何而生替代方案、灵感来源与三大基石组件深度解析【免费下载链接】fastapiFastAPI framework, high performance, easy to learn, fast to code, ready for production项目地址: https://gitcode.com/GitHub_Trending/fa/fastapi本文基于 FastAPI 官方文档 Alternatives, Inspiration and Comparisons 整理并扩展系统回答三个问题FastAPI 的设计灵感来自哪些前代框架与工具、它在功能取舍上学到了什么以及它实际依赖的 Pydantic、Starlette、Uvicorn 三个基石组件分别承担什么职责。读完后你不仅能理解 FastAPI 每一处设计决策的来历如自动 API 文档、类型提示驱动的校验、依赖注入、ASGI 异步底座还能通过仓库源码定位到对应的实现与版本约束从而对技术选型有完整的判断依据。一、设计背景从拒绝造新框架到不得不自建FastAPI 官方文档开宗明义FastAPI 不会存在如果没有前人的工作。在此之前已有大量工具启发了它的诞生。作者明确表示多年来一直在刻意避免创建一个新框架最初尝试用多个框架 插件 工具的组合来覆盖 FastAPI 现在提供的所有能力。但当作者穷尽了组合方案后发现已经没有办法在不损失体验的情况下拼出全部特性——于是最终只能创建一个集大成者吸收前人工具的最佳想法以最优方式组合并且利用了当时甚至还不存在的语言特性Python 3.6 的类型提示 / type hints。这段话解释了 FastAPI 的定位它不是从零发明而是对 Django、Flask、DRF、Requests、Swagger/OpenAPI、Marshmallow、Webargs、APISpec、Flask-apispec、NestJS、Sanic、Falcon、Molten、Hug、APIStar 等工具的经验做了一次工程化收敛。二、前代工具的逐一点评与启发2.1 Django最流行的 Python 框架但生而面向 HTMLDjango是最流行、被广泛信任的 Python 框架被用来构建 Instagram 等系统。但它与关系型数据库MySQL、PostgreSQL 等耦合较紧若想把 NoSQL 数据库Couchbase、MongoDB、Cassandra 等作为主存储引擎并不容易。更关键的是它的设计目标是在后端生成 HTML而不是为现代前端React、Vue.js、Angular或其他系统如 IoT 设备提供 API 服务。因此它没有给 FastAPI 留下直接的功能启发但它确立的全功能框架心智是 FastAPI 对标的参照系之一。2.2 Django REST Framework自动 API 文档的第一块拼图Django REST Framework (DRF)是为 Django 构建 Web API 的灵活工具包被 Mozilla、Red Hat、Eventbrite 等众多公司使用。它是**自动 API 文档概念最早期的范例之一**——这正是启发作者寻找 FastAPI的第一条线索。给 FastAPI 的启发拥有一个自动化的 API 文档 Web 用户界面。一个值得注意的细节DRF 的作者是 Tom Christie——同时也是 Starlette 和 Uvicorn 的作者而这两者正是 FastAPI 的底座。FastAPI 的整个技术栈可以看作Tom Christie 的生态 Pydantic 类型提示的组合这一事实也解释了为何 FastAPI 与 Starlette、Uvicorn 的配合如此紧密。2.3 Flask微框架哲学的来源Flask是典型的microframework不内置数据库集成也不默认附带 Django 那种全家桶。这种简单性和灵活性反而允许你自由地使用 NoSQL 作为主数据存储。它简单易学尽管文档在某些地方偏技术化也常用于不需要数据库、用户管理等 Django 内建功能的应用。作者明确指出这种组件解耦、微框架、可按需扩展的特性是他希望保留的关键设计。正因为 Flask 足够简单它似乎与构建 API 的场景非常匹配——下一步自然就是为 Flask 找一个DRF。给 FastAPI 的启发成为一个微框架方便自由混搭所需工具和组件提供简单、易用的路由系统。FastAPI 的微框架属性在源码中体现得很直接核心应用类就是一个对 Starlette 的轻量继承绝大多数复杂度被推迟到按需使用时才产生如 OpenAPI 生成在首次调用时才执行并缓存见 applications.py 的 openapi() 方法。2.4 Requests客户端库对服务端 API 设计的反向塑造FastAPI 并非 Requests 的替代品——两者的作用域完全不同Requests 是使用API 的客户端库FastAPI 是构建API 的服务端框架二者位于请求链路的两端互为补充。实际上在 FastAPI 应用内部调用外部 API 时使用 Requests 非常常见。Requests 的设计极为简单直观、默认值合理同时又强大且可定制。例如发一个GET请求response requests.get(http://example.com/some/url)而 FastAPI 中对应的 API 路径操作可以写成注意第 1 行的对称性app.get(/some/url) def read_url(): return {message: Hello World}对比requests.get(...)与app.get(...)命名与心智模型高度一致。给 FastAPI 的启发拥有简单直观的 API直接使用 HTTP 方法名操作作为装饰器直白易懂默认值合理但保留强大的定制能力。这一启发直接对应源码中的路由 API 设计app.get()/app.post()等路径操作方法与app.get装饰器等价路由注册入口见 applications.py 的 add_api_route()。2.5 Swagger / OpenAPI选择开放标准而非私有 Schema作者从 DRF 身上最想继承的功能就是自动 API 文档。随后他发现存在一个用 JSON或 JSON 的超集 YAML描述 API 的标准——Swagger并且已有基于 Swagger 的 Web 用户界面存在。这意味着只要为 API 生成 Swagger 文档就能自动获得这些现成的 UI。Swagger 后来移交给了 Linux Foundation并更名为OpenAPI。因此谈 2.0 版本时人们习惯说Swagger谈 3.x 及以后则说OpenAPI。给 FastAPI 的启发采用开放标准OpenAPI作为 API 规范而不是自定义 schema集成基于标准的 UI 工具Swagger UI 与 ReDoc。这两个 UI 被选中的理由是相当流行且稳定而社区中还有数十种 OpenAPI UI 替代品可以配合 FastAPI 使用。这一点在仓库源码中有清晰的落地FastAPI构造函数提供docs_url默认/docs、redoc_url默认/redoc等参数均可为None关闭见 applications.pysetup()方法在启动时把/openapi.jsonopenapi_url、/docsSwagger UI HTML、/redocReDoc HTML与 OAuth2 重定向路由挂到应用上见 applications.py 的 setup()OpenAPI schema 的生成入口是 openapi/utils.py 的 get_openapi()默认openapi_version3.1.0即生成的是 OpenAPI 3.x 规范。换言之DRF 留下的自动文档想法最终通过OpenAPI 标准 现成 UI这条路线在 FastAPI 中实现。2.6 Flask 生态的 REST 组件链Marshmallow → Webargs → APISpec → Flask-apispec作者为 Flask 寻找DRF时逐个评估了 Flask REST 生态。值得注意的是这些 Flask REST 框架中许多已经停更或被放弃存在若干悬而未决的问题使其不再适用。Marshmallow序列化与校验API 系统需要的核心能力之一是数据序列化serialization又称 marshalling、conversion把代码中的数据Python 对象转换成可经网络传输的形式例如把数据库对象转成 JSON、把datetime对象转成字符串。另一项核心能力是数据校验确保数据在给定参数下合法例如某字段必须是int而不是任意字符串。没有校验系统这些检查只能在代码里手工完成。Marshmallow 正是为此而生作者此前大量使用过它。但它诞生于 Python 类型提示出现之前定义每个 schema 都需要使用 Marshmallow 提供的特定工具类。启发用代码而非专用 DSL 类定义提供数据类型与校验的schema并让文档自动化。Webargs入站数据解析API 的另一大刚需是从入站请求中解析parsing数据并转换成 Python 数据。Webargs 正是构建在多个框架包括 Flask之上的工具底层用 Marshmallow 做校验且与 Marshmallow 出自同一批开发者。启发对入站请求数据做自动校验。APISpec文档补齐但暴露了双语法痛点Marshmallow Webargs 解决了校验、解析与序列化但还缺文档于是有了 APISpec——它是多框架插件也有 Starlette 插件工作方式是在路由处理函数的 docstring 里用 YAML 格式书写 schema 定义然后生成 OpenAPI schema。问题随之而来这又形成了一套嵌在 Python 字符串里的微语法一大坨 YAML编辑器帮不上什么忙而且一旦修改了参数或 Marshmallow schema 却忘了同步修改 docstring 里的 YAML生成的 schema 就会过时。启发支持 OpenAPI 这一 API 开放标准。Flask-apispec组合拳与最终形态Flask-apispec 是把这些组件串起来的 Flask 插件用 Webargs 与 Marshmallow 的信息通过 APISpec 自动生成 OpenAPI schema。作者评价它很棒但被严重低估理应比许多 Flask 插件更流行——可能原因只是文档过于简洁抽象。它解决了在 Python docstring 里写 YAML的痛点。Flask Flask-apispec Marshmallow Webargs是作者构建 FastAPI 之前最爱的后端技术栈并由此衍生了多个全栈生成器项目这些生成器后来又成为 FastAPI 项目生成器Project Generators的基础参见 Project Generators 文档。启发OpenAPI schema 应从同一份定义序列化与校验的代码中自动生成——这是 FastAPI 类型提示驱动的文档能力的设计原点。这条演进链清晰地展示了 FastAPI 数据层的设计逻辑与其让开发者维护代码 一套 YAML 文档两份真相不如让类型提示 Pydantic 模型同时驱动校验、序列化与 OpenAPI 生成。FastAPI 当前对 Pydantic 的最低版本约束见 pyproject.tomlpydantic2.9.0并配合pydantic-settings、pydantic-extra-types等生态包。2.7 NestJS与 Angular依赖注入与类型支持的对照实验NestJS 甚至不是 Python——它是一个受 Angular 启发的 JavaScriptTypeScriptNodeJS 框架但实现了与 Flask-apispec 类似的目标它内置了受 Angular 2 启发的依赖注入系统与作者所知的其他 DI 系统一样需要预注册injectables增加了啰嗦度和代码重复参数用 TypeScript 类型类似 Python 类型提示描述编辑器支持相当好但 TypeScript 类型在编译为 JavaScript 后不再保留因此无法同时靠类型完成校验、序列化与文档。加上一些设计决策要在很多地方添加装饰器才能同时获得校验、序列化与自动 schema 生成代码相当冗长它对嵌套模型的处理不佳如果请求 JSON body 是包含内层嵌套 JSON 对象的对象它就无法被正确文档化和校验。给 FastAPI 的启发用 Python 类型获得优秀的编辑器支持拥有强大的依赖注入系统并找到最小化代码重复的方式。FastAPI 的依赖注入系统正是对这一启发以及对 NestJS 预注册模式的改进的落地依赖按类型/协程签名解析、按需惰性求值核心求解逻辑在 dependencies/utils.py 的 solve_dependencies()与 NestJS 不同FastAPI 的依赖通过函数参数声明即可生效无需集中预注册。2.8 Sanic异步性能路线的开路者Sanic是最早一批基于asyncio的极快 Python 框架之一设计目标是高度类似 Flask。技术细节它用uvloop替代了 Python 默认的asyncio事件循环这是它速度极快的原因。它明显启发了 Uvicorn 与 Starlette而后者目前在公开基准测试中比 Sanic 更快。给 FastAPI 的启发找到一种方式获得疯狂的性能。这就是为什么FastAPI 基于 Starlette——它是当时经第三方基准测试验证的最快框架。2.9 Falconrequest/response 双对象设计的取舍Falcon是另一个高性能 Python 框架设计为极简、可作其他框架如 Hug的地基。它的设计是函数接收两个参数——request 与 response从 request读数据、向 response写数据。由于这种设计无法用标准 Python 类型提示作为函数参数来声明请求参数和 body因此数据校验、序列化与文档只能在代码中手工完成或以 Hug 这样的上层框架形式实现。受 Falcon 这种一 request 一 response 双参数设计启发的其他框架也存在同样的区分。给 FastAPI 的启发寻找获得高性能的方式。 同时Hug基于 Falcon启发了 FastAPI 在路径操作函数中声明response参数。不过在 FastAPI 中它是可选的主要用于设置响应头、Cookie 与替代状态码。2.10 Molten思路相近但取舍不同Molten是作者在建 FastAPI 早期发现的框架理念相当相似基于 Python 类型提示、由类型驱动校验与文档、内置依赖注入系统。不同之处在于它没有使用 Pydantic 这类第三方数据校验/序列化/文档库而是自研了一套因此其数据类型定义的可复用性较差配置稍微更啰嗦基于 WSGI而非 ASGI无法享受 Uvicorn、Starlette、Sanic 等工具带来的高性能其依赖注入系统要求预注册依赖且按声明的类型解析依赖因此不可能声明多个提供同一类型的组件路由集中声明在一个地方引用的函数定义在别处而非像 Flask/Starlette 那样用装饰器直接放在处理函数上方。这更接近 Django 的风格把逻辑上紧耦合的东西在代码中拆开了。给 FastAPI 的启发用模型属性的default 值来定义数据类型的额外校验以改善编辑器支持——这一点在当时 Pydantic 中尚不具备。这一启发实际上促使作者更新了 Pydantic 的相应部分以支持同样的校验声明风格该功能如今已在 Pydantic 中原生提供。2.11 Hug类型提示声明参数的先驱Hug是最早用 Python 类型提示声明 API 参数类型的框架之一这是一个启发了众多后续工具的好想法。它当时在声明中使用的是自定义类型而非标准 Python 类型但依然是巨大的进步。它也是最早生成以 JSON 描述整个 API的自定义 schema 的框架之一——不过它没有基于 OpenAPI / JSON Schema 这类标准因此难以与 Swagger UI 等工具直接集成但想法本身极具创新性。它还有一个少见而有趣的特性用同一个框架既可以创建 API也可以创建 CLI。由于它基于同步 Web 框架的旧标准 WSGI它无法处理 WebSocket 等场景尽管性能依然很高。注Hug 的作者是 Timothy Crosley他也是自动排序 import 的工具isort的作者。启发总结Hug 启发了 APIStar 的部分设计也是作者认为最有前景的工具之一与 APIStar 并列。它帮助启发了 FastAPI 用类型提示声明参数、自动生成 API schema以及用response参数设置响应头与 Cookie 的做法。2.12 APIStar≤ 0.5直接的精神前辈在决定构建 FastAPI 前夕作者发现了APIStar。它几乎拥有作者想要的一切且设计优秀是他所见过的最早一批早于 NestJS 和 Molten用 Python 类型提示声明参数与请求的框架实现且与 Hug 差不多同时期发现。区别在于APIStar 使用的是 OpenAPI 标准在多处基于同一套类型提示实现自动数据校验、序列化与 OpenAPI schema 生成body schema 定义没有采用 Pydantic 那样的标准 Python 类型提示而更接近 Marshmallow因此编辑器支持没那么好——但即便如此APIStar 仍是当时最佳可用选项当时它的性能基准测试最好仅被 Starlette 超越最初没有自动 API 文档 Web UI但作者知道可以为它加上 Swagger UI有依赖注入系统同样需要预注册组件作者始终没能在完整项目中使用它因为它缺少安全集成无法替代基于 Flask-apispec 的全栈生成器的全部功能——为它提交一个添加安全功能的 PR一直挂在作者的待办列表里。随后项目重心发生了转移由于作者需要专注于 StarletteAPIStar 不再是 API Web 框架如今它是一套校验 OpenAPI 规范的工具体系而非 Web 框架。注APIStar 也是 Tom Christie 的作品——他同时创建了 Django REST Framework、StarletteFastAPI 的底座与 UvicornStarlette 与 FastAPI 使用的服务器。给 FastAPI 的启发存在本身。用同一套 Python 类型同时声明数据校验、序列化与文档同时获得优秀编辑器支持——作者认为这是一个天才般的想法。在长期寻找同类框架、测试大量替代方案后APIStar 是最佳选项。而当 APIStar 停止作为服务器存在、Starlette 被创造出来并提供了更好的地基时这成为构建FastAPI的最终灵感。作者把 FastAPI 视为 APIStar 的精神继承者spiritual successor并在特性、类型系统及其他方面基于前述所有工具的经验做了改进与扩充。三、FastAPI 真正使用的三大基石Pydantic、Starlette、Uvicorn与灵感来源不同下面三个组件是 FastAPI 当前实际依赖并集成的核心。依赖版本约束在 pyproject.toml 中有明确定义starlette0.46.0、pydantic2.9.0、uvicorn[standard]0.12.0、python-multipart0.0.18等可直接作为生产环境的选型参考。3.1 Pydantic类型提示驱动的校验、序列化与文档Pydantic 是基于 Python 类型提示定义数据校验、序列化与文档使用 JSON Schema的库因此极其直观。它与 Marshmallow 对等但基准测试中比 Marshmallow 更快由于基于同样的 Python 类型提示编辑器支持极佳。FastAPI 用它来处理所有数据校验、数据序列化与自动模型文档基于 JSON Schema。FastAPI 再把这份 JSON Schema 数据放进 OpenAPI与其余所有元数据一起组成完整 schema。这与第二节 Flask 生态部分schema 应从同一份代码自动生成的启发完全闭环。3.2 StarletteASGI 微框架底座FastAPI 的父类Starlette 是轻量级ASGI构建异步 Python Web 应用的新标准框架/工具包非常适合构建高性能 asyncio 服务。它简单直观设计上易于扩展、组件模块化特性包括令人印象深刻的高性能WebSocket 支持进程内后台任务in-process background tasks启动/关闭事件startup/shutdown events基于 HTTPX 的测试客户端CORS、GZip、静态文件、流式响应Session 与 Cookie 支持100% 测试覆盖率100% 类型注解代码库极少的硬依赖。Starlette 是当前被测的最快 Python 框架仅被 Uvicorn 超越——而 Uvicorn 不是框架是服务器。Starlette 提供了 Web 微框架的全部基础功能但不提供自动数据校验、序列化或文档。这正是 FastAPI 在其上添加的主要内容——全部基于 Python 类型提示经由 Pydantic外加依赖注入系统、安全工具、OpenAPI schema 生成等。技术细节ASGI 是由 Django 核心团队参与开发的新标准。它目前还不是正式 Python 标准PEP尽管流程已在推进中。但它已被多个工具当作标准使用这大幅改善了互操作性你可以把 Uvicorn 换成任何 ASGI 服务器如 Daphne 或 Hypercorn也可以接入 ASGI 兼容工具如python-socketio。FastAPI 用它来处理所有核心 Web 部分并在其上叠加特性。类FastAPI直接继承自类Starlette——这一点可以在源码中直接验证applications.py 第 42 行 即为class FastAPI(Starlette):。因此你用 Starlette 能做的一切都能直接用 FastAPI 做——它基本上是打了强化针的 Starlette。3.3 Uvicorn推荐的 ASGI 服务器Uvicorn 是构建在uvloop与httptools之上的高速 ASGI 服务器。它不是 Web 框架而是服务器——例如它不提供按路径路由的工具那是 Starlette或 FastAPI这类框架在其上提供的事情。它是 Starlette 与 FastAPI 的推荐服务器。FastAPI 推荐它作为运行 FastAPI 应用的主 Web 服务器。你也可以使用--workers命令行选项获得异步多进程服务器生产部署的完整方案含 Docker 场景下 worker 数量的取舍见 Deployment 文档 与 Docker 部署指南。例如在多 worker 场景下的典型写法摘自部署文档CMD [fastapi, run, app/main.py, --port, 80, --workers, 4]其中--workers将 worker 进程数设为 4注意容器化部署中通常一个容器一个 Uvicorn 进程、水平扩展容器而不是在容器内堆 worker见 deployment/docker.md。四、架构落点从文档理念到 FastAPI 源码的对应关系把全文的灵感—落地线索汇总可以在仓库中逐条对上前代工具的启发FastAPI 中的落点仓库内可查证DRF 的自动 API 文档setup()自动挂载/docs、/redoc、/openapi.json路由见 applications.pySwagger/OpenAPI 标准get_openapi()默认生成 OpenAPI 3.1.0 schema见 openapi/utils.pyMarshmallow/Webargs 的校验与序列化由 Pydantic 承担版本约束pydantic2.9.0见 pyproject.tomlFlask 的微框架 简单路由FastAPI直接继承Starlette见 applications.py路由 API 如app.get()NestJS 的依赖注入去预注册化solve_dependencies()按声明惰性求解见 dependencies/utils.pyFalcon/Hug 的response参数FastAPI 中response为可选参数主要用于设置头、Cookie 与替代状态码Molten 的default 值即校验已回馈 Pydantic模型属性的默认值可同时承载校验声明Sanic/Starlette 的性能路线异步 ASGI 底座WebSocket、后台任务等能力继承自 StarletteAPIStar 的同类型提示驱动一切类型提示同时驱动校验、序列化、OpenAPI 生成openapi()首次调用后缓存于app.openapi_schema见 applications.pyAPIStar 缺失的安全集成FastAPI 内建fastapi/security/模块OAuth2、HTTP Basic/Bearer/Digest、API Key 的 query/header/cookie 形式、OpenID Connect 等见 security 目录五、性能与基准理解 Uvicorn、Starlette 与 FastAPI 的分层差异要理解、对比并看清 Uvicorn、Starlette 与 FastAPI 之间的性能差异与各自角色服务器 / 框架 / 框架之上叠加层文档建议阅读专门的 Benchmarks 章节。简而言之Uvicorn 是服务器层最快但它不提供路由等框架能力Starlette 是框架层被测最快框架FastAPI 在 Starlette 之上叠加校验、文档与安全等能力——性能与功能的取舍正是第二节中 Sanic 到 APIStar 这条性能—能力演进链的最终答案。六、小结FastAPI 的每一项核心设计都能在某个前代工具中找到源头DRF 给了自动文档的初心Flask 给了微框架的形态Requests 给了app.get式的直觉 APISwagger/OpenAPI 给了开放标准的选择Marshmallow/Webargs/Flask-apispec 给了一份代码同时定义校验、序列化与文档的诉求NestJS 与 APIStar 给了类型提示驱动与依赖注入的蓝图Sanic 与 Falcon 定义了性能目标Hug 与 Molten 则分别贡献了类型提示参数与默认值即校验的细节。而真正让这一切成为现实的是 Pydantic、Starlette 与 Uvicorn 这三大基石——它们既是灵感也是 FastAPI 源码中可逐行验证的依赖事实。理解这条灵感 → 落地的完整链路是把握 FastAPI 设计哲学与正确做技术选型的最短路径。【免费下载链接】fastapiFastAPI framework, high performance, easy to learn, fast to code, ready for production项目地址: https://gitcode.com/GitHub_Trending/fa/fastapi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考