ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

FastAPI 的设计渊源与选型解析:从 Django、Flask、APIStar 到 Starlette 与 Pydantic 的灵感溯源

2026/9/5 23:17:36 拓冰建站 浏览量
FastAPI 的设计渊源与选型解析:从 Django、Flask、APIStar 到 Starlette 与 Pydantic 的灵感溯源 FastAPI 的设计渊源与选型解析从 Django、Flask、APIStar 到 Starlette 与 Pydantic 的灵感溯源【免费下载链接】fastapiFastAPI framework, high performance, easy to learn, fast to code, ready for production项目地址: https://gitcode.com/GitHub_Trending/fa/fastapiFastAPI 并非凭空诞生而是作者多年间对比 Django、Flask、Requests、NestJS、Sanic、Falcon、Molten、Hug、APIStar 等十余种框架后将其各自最优思想重新组合的产物。本篇基于仓库中《Alternativen, Inspiration und Vergleiche》替代品、灵感与对比文档展开梳理 FastAPI 的灵感来源、所依赖的核心组件Pydantic、Starlette、Uvicorn并结合当前仓库源码印证这些设计决策是如何真正落地的帮助读者理解 FastAPI “为什么是现在这个样子”。一、写作背景为什么需要一个新框架原文档开宗明义FastAPI 如果没有他人的先行工作就不会存在。作者在相当长的时间里一直避免创建新框架而是先尝试用多种现有框架、插件和工具的组合来覆盖 FastAPI 现在所覆盖的全部功能。直到某个节点他发现没有任何单一工具能同时提供所需的全部能力于是决定打造一个新框架吸收此前各类工具中最好的想法以当时尚不可用的语言特性Python 3.6 类型注解为地基把它们组合到最优形态。这个“组合最佳实践”的思路贯穿整份文档每个被讨论的工具最后都会落到一条或多条“FastAPI 从中获得了什么”的结论上。二、先行工具FastAPI 从谁那里学到了什么2.1 DjangoDjango 是最流行的 Python 框架拥有极高的信任度被用于构建 Instagram 这样的系统。但它有两个与 FastAPI 目标定位不同的特点与关系型数据库MySQL、PostgreSQL 等耦合较紧因此把它换成 NoSQL 数据库Couchbase、MongoDB、Cassandra 等作为主存储并不轻松定位是后端生成 HTML而不是为现代前端React、Vue.js、Angular或 IoT 设备等系统提供 API。FastAPI 选择了与 Django 相反的取向不做 HTML 渲染不做数据库强绑定专注 API。2.2 Django REST FrameworkDRFDRF 是为在 Django 之上构建 Web API 而开发的灵活工具包被 Mozilla、Red Hat、Eventbrite 等公司使用。它对 FastAPI 最关键的一点贡献是它是“自动生成 API 文档”的最早范例之一也是直接激发 FastAPI 诞生动机的最早想法之一。值得注意的血缘关系DRF 的作者是 Tom Christie他也是 Starlette 和 Uvicorn 的创建者——而 Starlette 与 Uvicorn 正是 FastAPI 的底层基座。FastAPI 从 DRF 继承的核心理念就一条拥有自动的 API 文档界面。2.3 Flask微框架思想的来源Flask 是一个“微框架”microframework不包含数据库集成也没有 Django 那样默认附带的大量功能。这种简单与灵活性带来了几个好处可以方便地把 NoSQL 数据库作为主数据存储由于足够简单学习曲线直观虽然文档局部偏技术化常被用于不需要数据库、用户管理等功能的轻量应用缺失的能力可用插件补齐。部件解耦 按需扩展的“微框架”模式是作者明确表示希望保留的关键特性。FastAPI 从 Flask 获得的启发包括做一个微框架让开发者能自由组合所需的工具和部件提供一个简单、好用的路由系统。作者当时的实践路径是先用 Flask 做 API 的骨架再寻找一个“Flask 版 Django REST Framework”来补齐文档与验证能力——这直接引出了下一节。2.4 Requests不是竞品而是设计范本FastAPI 其实不是Requests 的替代品二者范围完全不同甚至在 FastAPI 应用内部使用 Requests 才是常态。两者的关系可以概括为Requests 是与 API 交互的客户端库FastAPI 是构建 API 的服务端库二者处于链条的两端互为补充。Requests 的设计被作者反复称道简单、直观、易用、默认值合理同时强大且可定制。一个GET请求只需一行response requests.get(http://example.com/some/url)对应的 FastAPI 路径操作见仓库教程示例 docs_src/first_steps/tutorial001_py310.py则是app.get(/some/url) def read_url(): return {message: Hello World}对照requests.get(...)与app.get(...)这种对称的直观性不是巧合。FastAPI 从 Requests 借鉴了三点简单、直观的 API 设计直接用 HTTP 方法名作为操作入口合理的默认值 强大的可配置能力并存。2.5 Swagger / OpenAPI开放标准而非私有格式作者在向 DRF 要“自动 API 文档”时发现了一个叫 Swagger 的标准用 JSON或其超集 YAML描述 API并且已经存在可渲染 Swagger 文档的 Web 界面。只要能自动产出 Swagger 描述就能免费获得这些现成的 UI。历史脉络Swagger 后来移交给了 Linux 基金会并更名为OpenAPI。因此业界习惯称 2.0 版本为 “Swagger”、3.0 及以后为 “OpenAPI”。FastAPI 的决策是采用开放标准OpenAPI而不是自定义私有 Schema并集成基于该标准的现成 UI 工具Swagger UIReDoc这两者因流行且稳定而被选为默认但用户完全可以替换成其他 OpenAPI 兼容界面。这条设计在源码中可以直接看到fastapi/openapi/docs.py 提供了get_swagger_ui_html与get_redoc_html两个函数分别生成默认的/docs和/redoc页面默认从 CDN 加载 Swagger UI 静态资源swagger-ui-bundle.js并且对嵌入script标签的 JSON 做了、、的转义处理以防止注入。2.6 Flask REST 生态Marshmallow、Webargs、APISpec、Flask-apispec这一组工具共同回答了一个问题API 框架到底需要哪些核心能力Marshmallow —— 序列化与验证API 系统的基础需求之一是数据“序列化”marshalling把代码中的 Python 数据例如数据库对象转换为可通过网络发送的形态如 JSON 对象、datetime转字符串。另一项核心需求是数据验证确保字段是int而不是任意字符串这对入站数据尤为重要——没有验证系统就只能手工写检查代码。Marshmallow 正是为此而生且诞生早于 Python 类型注解定义 Schema 必须使用它自带的工具类和字段类。FastAPI 从中获得的启发用代码定义“Schema”同时自动获得数据类型声明和验证能力——但 FastAPI 选择了用标准 Python 类型注解 Pydantic 来实现而不是自定义字段类。Webargs —— 自动解析入站请求API 还需要从入站请求中解析parsing并转换为 Python 数据。Webargs 为包括 Flask 在内的多个框架提供这一能力底层复用 Marshmallow 做验证两者出自同一批开发者。FastAPI 的启发自动验证入站请求数据。APISpec —— 补上文档这一环Marshmallow Webargs 覆盖了验证、解析、序列化唯独缺文档。APISpec 作为多框架插件也有 Starlette 插件补位在路由函数的docstring 中用 YAML 写 Schema 定义然后生成 OpenAPI Schema。但它引入了一个经典问题在 Python 字符串里再套一层微语法大段 YAML。编辑器几乎帮不上忙一旦参数或 Marshmallow Schema 变了而忘了同步改 YAML docstring生成的 Schema 就会过期失真。FastAPI 的启发支持 API 的开放标准 OpenAPI但绝不重蹈“YAML 写在字符串里”的覆辙。Flask-apispec —— 组合拳的巅峰Flask-apispec 是一个 Flask 插件把 Webargs、Marshmallow 和 APISpec 串起来利用前两者的信息通过 APISpec 自动生成 OpenAPI Schema。作者评价它“很棒但被严重低估”文档过于紧凑抽象可能是它不够流行的原因。它解决了“在 docstring 里写 YAML”的问题。在 FastAPI 诞生之前Flask Flask-apispec Marshmallow Webargs 就是作者以及多个外部团队的主力后端技术栈并据此孵化了多个 Flask 全栈生成器项目而这些全栈生成器后来又成为 FastAPI 项目生成器的基础参见 项目生成文档。FastAPI 从中提炼出的核心思想从同一份既定义序列化又定义验证的代码自动生成 OpenAPI Schema——这是整个 FastAPI 设计哲学的总纲。2.7 NestJS与 Angular非 Python 世界的对照NestJS 是一个受 Angular 启发的 TypeScript/Node.js 框架不是 Python但它达到了类似 Flask-apispec 的效果提供了几个重要参照点内置依赖注入系统灵感来自 Angular 2但要求预先注册“Injectables”——与作者所知的其他 DI 系统一样造成代码冗长和重复参数用 TypeScript 类型标注类似 Python 类型注解因此编辑器支持相当好但 TypeScript 类型在编译为 JavaScript 后不会保留到运行时类型无法同时承担验证、序列化和文档三个职责于是必须在多处堆叠装饰器代码变得相当啰嗦对嵌套模型支持不佳请求体里嵌套 JSON 对象难以被正确文档化和验证。FastAPI 的启发用 Python 类型获得优秀的编辑器支持具备强大的依赖注入系统同时最小化代码重复不做预注册直接在函数签名声明。2.8 Sanicasyncio 高性能路线的先驱Sanic 是最早基于asyncio的极速 Python 框架之一设计上刻意贴近 Flask。技术上它用uvloop替代了标准asyncio事件循环这让它获得了速度也直接启发了 Uvicorn 与 Starlette 的实现后两者在公开基准测试中比 Sanic 更快。FastAPI 从 Sanic 得到的启示是必须找到一条取得卓越性能的路径。因此 FastAPI 选择构建在 Starlette 之上——按第三方基准测试它是当时最快的框架之一。2.9 Falcon两种 API 设计哲学的分野Falcon 是另一个高性能 Python 框架风格极简是 Hug 等框架的底层。它的方法签名是(request, response)两个对象手动从 Request “读”、向 Response “写”。这个设计带来的直接后果是无法用标准 Python 类型注解把请求参数和请求体声明为函数参数数据验证、序列化和文档要么手工写在代码里要么在 Falcon 之上再盖一层框架Hug 就是这么做的。FastAPI 选择了与之正交的另一条路类型注解即声明。FastAPI 从 Falcon连同基于它的 Hug借鉴的另一点是在函数中声明一个response参数。FastAPI 中该参数是可选的主要用于设置 Header、Cookie 和替代状态码。在源码中可以直接验证这一点fastapi/routing.py 的路由处理逻辑中存在response: Response | None None的声明约第 407 行端点函数签名里带上response: Response时框架会将其注入。2.10 Molten类型注解路线的同路人作者是在 FastAPI 开发早期发现 Molten 的两者理念高度相似基于 Python 类型注解从类型推导验证与文档依赖注入系统。但 Molten 有几个与 FastAPI 分道扬镳的地方不依赖 Pydantic 等第三方数据验证/序列化/文档库而是自带一套导致其数据类型定义的可复用性差需要更繁琐的配置基于 WSGI 而非 ASGI无法享受 Uvicorn、Starlette 一类 ASGI 工具链的高性能DI 系统要求预注册依赖且按声明类型解析因此无法声明两个提供同一类型的不同“组件”路由集中在单处声明用函数引用而非直接放在处理函数上方的装饰器更接近 Django 风格把逻辑上紧密耦合的东西在代码里拆开了。FastAPI 反过来从 Molten 获益的一点是允许通过模型属性的“默认值”来附加数据验证声明——这改善了编辑器支持而且这一做法最终被上游吸收如今 Pydantic 已原生支持同样的验证声明风格即Field(...)等写法FastAPI 只是顺势使用。2.11 Hug类型注解声明 API 的最早实践者Hug 是最早用 Python 类型注解声明 API 参数类型的框架之一尽管用的是自定义类型而非标准 Python 类型这已经是一个巨大的进步并启发了包括 APIStar 在内的后续工具。Hug 还是最早生成自定义 JSON Schema来描述整个 API 的框架之一——但它没有基于 OpenAPI / JSON Schema 标准因此难以接入 Swagger UI 等生态工具。Hug 还有一个独特能力同一框架既能写 API 也能写 CLI。不过它基于 WSGI不支持 WebSocket 等特性性能依然不错。附带一提Hug 的作者是 Timothy Crosley他也是isort自动排序 import 的工具的作者。Hug 对 FastAPI 的具体启发用 Python 类型注解声明参数并自动生成定义整个 API 的 Schema声明response参数来设置 Header 和 Cookie它本身还启发了 APIStar 的部分设计。2.12 APIStar 0.5最接近成品的一次在决定创建 FastAPI 前不久作者发现了 APIStar——“几乎拥有他想要的一切而且设计出色”。它是作者见过的最早一批用 Python 类型注解声明参数和请求的框架实现之一早于 NestJS 和 Molten与 Hug 大致同期发现但APIStar 用的是 OpenAPI 标准并且多处基于同一份类型注解实现了自动数据验证、序列化和 OpenAPI Schema 生成。不足之处请求体 Schema 定义没有使用与 Pydantic 相同的 Python 类型注解更接近 Marshmallow 风格编辑器支持打折扣——但当时它仍是最佳可选项性能基准当时最好仅次于 Starlette最初没有内建文档 Web 界面作者知道可以自行挂上 Swagger UIDI 系统同样需要预注册组件没有安全security集成作者本想提 PR 补上以便用它替换基于 Flask-apispec 的全栈生成器但项目方向变了。命运转折APIStar 的开发者转向了 StarletteAPIStar 不再作为 Web 框架演进如今它只是一组校验 OpenAPI 规格的校验工具作者注明此节讨论的是 0.5 及以前版本。APIStar 的创建者正是 Tom Christie——DRF、Starlette、Uvicorn 的作者。作者对 FastAPI 的定位一句话总结得最重FastAPI 是 APIStar 的“精神续作”spiritual successor基于对所有这些先行工具经验的总结改进并扩展了它的功能、类型系统与其他部分。Starlette 的诞生提供了更好的地基成了 FastAPI 开发的最后临门一脚。三、FastAPI 实际使用的组件灵感归灵感真正撑起 FastAPI 的是三个组件。这一节可以逐条在仓库源码中对上号。3.1 Pydantic验证、序列化、JSON Schema 三位一体Pydantic 是基于 Python 类型注解定义数据验证、序列化和文档通过 JSON Schema的库因此极其直观。它可比作 Marshmallow但基准测试中更快且因为基于同样的类型注解编辑器支持一流。FastAPI 用它完成全部的数据验证全部的数据序列化基于 JSON Schema 的自动模型文档——FastAPI 再把这份 JSON Schema 装配进 OpenAPI。依赖声明可以在 pyproject.toml 中确认核心依赖为starlette0.46.0与pydantic2.9.0另有typing-extensions、typing-inspection、annotated-doc而standard可选依赖组中还包含uvicorn[standard]、python-multipart、email-validator等。3.2 StarletteFastAPI 的继承者身份Starlette 是一个轻量级ASGI框架/工具包专为构建高性能异步服务设计简单直观、模块化、易扩展。它提供出色的性能WebSocket 支持同进程后台任务Background TasksStartup / Shutdown 事件基于 HTTPX 的测试客户端CORS、GZip、静态文件、流式响应Session 与 Cookie 支持100% 测试覆盖与全类型注解代码库极少的强依赖。文档原文称 Starlette 是当时“测试过最快的 Python 框架”仅次于并非框架而是服务器的Uvicorn。它提供微框架的全部基础能力但不提供自动数据验证、序列化和文档——而这正是 FastAPI 用类型注解 Pydantic 补上的第一块拼图其余还包括依赖注入系统、安全工具、OpenAPI 生成等。这一点在源码中是铁的事实fastapi/applications.py 中FastAPI类直接继承自 Starlette 的同名类from starlette.applications import Starlette ... class FastAPI(Starlette): FastAPI app class, the main entrypoint to use FastAPI. 也就是说文档里那句“FastAPI 本质上是被加强过的 Starlette”不是比喻——凡是 Starlette 能做的FastAPI 应用都能直接做。ASGI 背景ASGI 是由 Django 核心团队部分成员推动的新标准文档写作时尚未成为正式 PEP。它已被多工具当作事实标准使用显著提升了互操作性可以把 Uvicorn 换成 Daphne、Hypercorn 等任意 ASGI 服务器或加入python-socketio这类 ASGI 兼容工具。3.3 Uvicorn推荐的 ASGI 服务器Uvicorn 是基于uvloop和httptools的高性能 ASGI 服务器。它不是 Web 框架——不提供路径路由之类的工具那是 Starlette或 FastAPI的职责。它是 Starlette 和 FastAPI 的推荐运行服务器支持--workers命令行选项以启用多进程异步服务器。部署细节参见 部署文档。四、把“灵感清单”映射回仓库源码前面大量“FastAPI 从 X 学到 Y”的结论都可以在当前仓库中逐一验证形成一张灵感到实现的对照表灵感来源FastAPI 中的落点仓库内证据DRF 的自动文档默认/docsSwagger UI与/redocfastapi/openapi/docs.py 的get_swagger_ui_html/get_redoc_htmlOpenAPI 开放标准从路由与 Pydantic 模型自动生成 OpenAPI Schemafastapi/openapi/utils.py 的get_openapiFlask 微框架 直观路由app.get(...)等路径操作方法fastapi/applications.py、docs_src/first_steps/tutorial001_py310.pyRequests 的requests.get对称设计app.get(/some/url)与requests.get(url)的镜像命名见第二节 2.4 的代码对照Falcon / Hug 的 response 参数可选response: Response参数用于 Header/Cookie/状态码fastapi/routing.py 的response: Response \| None NoneAPIStar / Molten / Hug 的类型注解驱动参数注解同时驱动验证、序列化、文档pyproject.toml 的pydantic2.9.0依赖声明Starlette 微框架基座FastAPI(Starlette)直接继承fastapi/applications.py#L42Sanic 启发的异步高性能路线依赖 Starlette Uvicorn 的 ASGI 栈pyproject.tomlstarlette0.46.0及uvicorn[standard]可选依赖最小化 DI 代码重复相对 NestJS/Molten/APIStar函数签名内直接声明依赖无预注册fastapi/dependencies/目录下的依赖解析实现例如 OpenAPI 生成的入口get_openapi在 fastapi/openapi/utils.pyFastAPI类构造时fastapi/applications.py即导入并接线了文档页函数swagger_ui_default_parameters中还固化了deepLinking、showExtensions等 Swagger UI 默认配置——这些正是“继承 Swagger/OpenAPI 生态”的具体体现。五、关于性能Uvicorn、Starlette、FastAPI 的关系理解三者分层服务器 / 框架 / 框架之上的 API 层是读懂 FastAPI 性能问题的关键Uvicorn是 ASGI 服务器事件循环层uvloop httptoolsStarlette是 ASGI 框架路由、中间件、WebSocket 等FastAPI是构建在 Starlette 之上、叠加类型注解驱动的验证/文档/DI/安全的 API 框架。FastAPI 自身并不声称比 Starlette 或 Uvicorn 快文档原文对此的口径是选择 Starlette 作为基座是因为它是第三方基准测试中最快的框架仅次于作为服务器的 Uvicorn。三者之间的基准对比与测试方法仓库内有专门的 Benchmarks 文档其中说明了如何复现对比 FastAPI 与其他框架的速度差异。六、小结FastAPI 是一张“最佳实践拼贴图”这份文档的价值不在于给出一份竞品横评而在于交代了 FastAPI 每一块设计积木的来源从DRF继承了“自动 API 文档”这一核心卖点从Flask继承了微框架、可组合、易学的形态从Requests继承了直觉化、对称的 API 风格从Swagger/OpenAPI 社区继承了开放标准优先、UI 工具生态复用的策略从Marshmallow/Webargs/APISpec/Flask-apispec继承了“同一份 Schema 定义同时驱动验证、序列化与文档”的哲学并刻意规避了 YAML-in-docstring 的腐化陷阱从NestJS借了依赖注入的雄心同时规避了预注册带来的代码重复从Sanic/Falcon确认了高性能异步路线的必要性从Molten/Hug验证了类型注解驱动可行从APIStar得到了临门一脚并以“精神续作”的姿态站在Starlette与Pydantic的地基上。阅读完本篇后你可以清楚地回答两个问题FastAPI 的每个标志性特性自动文档、类型注解验证、response参数、无预注册的 DI、ASGI 高性能基座分别是从哪个前辈那里“抄作业”的以及这些特性在当前仓库的哪些源码文件中得到了实现——这正是理解 FastAPI 设计取舍的最短路径。【免费下载链接】fastapiFastAPI framework, high performance, easy to learn, fast to code, ready for production项目地址: https://gitcode.com/GitHub_Trending/fa/fastapi创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考