烧瓶死了吗？ FastAPI 是未来吗？-Python教程-PHP中文网

Is Flask Dead? Is FastAPI the Future?
在我的相关搜索中，我注意到即使到了 2024 年，仍有相当多的人推荐 Flask 作为 Python Web 框架。不过，在我看来，“Flask 正在走向淘汰，FastAPI 代表着未来”。这就是我写这篇文章的原因。欢迎大家参与讨论，提出反驳。

Flask 与 FastAPI

Flask 在 Python 开发者心中占有重要地位。如果您是一名 Web 开发人员，我敢打赌您很可能使用过 Flask，但也许您从未涉足过 FastAPI。

这里有两个证据：

近一两年新出现的与Web开发相关的Python新项目中，几乎所有涉及Web开发的项目都采用了FastAPI。
截至2024年12月25日，在GitHub上，FastAPI的star数（78.9k）已经超过Flask（68.4k）。

现在我们来看看官方Python开发者调查中Web框架占比的变化。

很明显，2019 年 FastAPI 甚至没有被列为选项，但到 2023 年，其份额已达到 25%。（目前，我们只有 2023 年之前的数据。）

需要注意的是，这个比例数据涵盖了现有系统，因此Django和Flask的比例不会快速下降。尽管如此，趋势还是很明显的。

我们都知道，Web 框架领域非常丰富，几乎每年都会出现新的框架。这些框架大多数都是短暂的，但也有一些能够持久存在。 FastAPI诞生于2018年底，2019年底左右开始崭露头角。那么，它如何在短短五年内超越2010年底诞生的Flask呢？接下来，让我们沿着时间线追溯Python Web框架和相关解决方案的发展历史，以便更好地理解。

Web 框架（插件、工具）的演变

FastAPI的作者是一位极其关注Python生态发展的开发者。扩展阅读链接2是作者写的《Alternatives, Inspiration and Comparisons》（https://fastapi.tiangolo.com/alternatives/），详细阐述了FastAPI从各个库中汲取的参考或启发。本文的发展历史部分也参考了这篇文章。我建议阅读原文，因为它包含了FastAPI出现的原理以及作者的一些设计理念。

烧瓶

Flask 是一个“微型”框架，与 Django 有着天壤之别。它只保留了少数核心功能，为了解耦，将其他功能拆分成几个库（例如 Jinja2、Werkzeug 等）。这给了开发者足够的自由，使他们能够毫不费力地为相关功能编写第三方插件。它的内部设计，如蓝图、上下文和用于表示路线、信号等的装饰器，在当时是相当先进的。再加上全面的文档，它对新手来说非常友好。

Flask REST 框架

由于其简单性，Flask 非常适合构建 API。然而，由于Flask本身没有任何内置功能，因此我们需要专门的REST框架。于是，flask-restful、Flask-RESTPlus、flask-api等框架相继出现。此外，在 REST 服务中，存在数据验证、解析和规范的需求，这导致了 Marshmallow、Webargs 和 APISpec 的出现，直到 Flask-apispec 出现。然而，在整个开发过程中，与 DRF 相媲美的 Flask REST 框架从未实现。

现阶段，Flask的缺点逐渐凸显出来。

Flask 最初的优势在于其灵活性和极简性，但这也意味着需要内部开发大量组件。这要么需要一家拥有专门开发人员进行开发和维护的大公司，要么需要非常有能力的个人开发人员。否则，插件很难达到生产质量，导致 Flask 第三方插件鱼龙混杂，无法保证长期维护。如前所述，其中许多库已经停止维护。

所以，即使在今天，如果你想用 Flask 构建一个 API 服务，你仍然需要拼凑各种组件。对于一些没有及时更新的组件，需要您自行排查。老手也许能够应付，但对于初学者来说，这相当令人畏惧，尤其是当他们想要应用最新的实践和概念时。

Asyncio 生态系统

从Python 3.5开始，asyncio已经成为未来的趋势。于是，出现了一些原生支持 asyncio 的 Web 框架，比如 aiohttp、Starlette、sanic。

这个时候，Flask 就不太适应了。社区添加对 asyncio 的支持进展缓慢，Flask 的原作者已经转而编写 Rust，将项目留给了两名维护者（现在只剩下一名维护者）。

apistar、melt等构建API服务的项目都为FastAPI的诞生提供了设计灵感。

快速API

然后，FastAPI 诞生了。作者原本是在寻求一个好的解决方案，但上述情况各有各的问题或局限性。于是，作者创建了这个新的框架。

为什么 FastAPI 脱颖而出

这是文章的核心部分。以下原因正是FastAPI能够取代Flask的原因。

使用 Pydantic 验证用户数据

API开发过程中，数据格式验证、解析、序列化是常规操作。多年来，出现了多种解决方案，目前 Pydantic 是首选：

from fastapi import FastAPI
from pydantic import BaseModel


class Item(BaseModel):
    name: str
    description: str | None = None
    price: float
    tax: float | None = None


app = FastAPI()


@app.post("/items/")
async def create_item(item: Item):
    return item

登录后复制

乍一看，这段代码看起来像是ORM或数据类的编写方式，但实际上，它使用Python原生的Type Hints语法来注释字段类型。例如，在上面的例子中，/items/请求中的Item的schema已经被明确定义，并且每个字段的值类型都是明确的。相比于旧有的使用 schema 描述甚至硬编码的方式，这种方式更加简洁，更符合 Python 风格，并且有更好的 IDE 支持。

目前，Pydantic 在用户数据验证领域占据主导地位。由于 FastAPI 内置了它，因此大大简化了验证过程，并减少了错误。这就是为什么FastAPI官网提到该解决方案可以减少开发者高达40%的错误。对于像Python这样的动态语言，如果不使用mypy进行类型检查，应用Pydantic是必不可少的。

此外，由于 Pydantic 的集成，向项目添加 ORM（例如 SQLAlchemy）变得非常容易。从请求中获得的对象可以直接传递到数据库，因为数据验证已经完成。反之亦然，从数据库检索到的对象也可以直接返回。

相比之下，Flask 在这方面有所欠缺。

异步设计

Flask 时代，代码执行是单线程、同步的。这意味着必须逐个处理请求，而其他请求会在前一个请求完成之前浪费时间等待 I/O 操作。另一方面，Asyncio 是最佳解决方案。它可以使 I/O 操作异步，让您无需等待任务完成即可获取任务结果，然后继续处理其他任务请求。

FastAPI 原生支持并发和异步代码。只要代码写得正确，就可以达到最高效率。因此，它被认为是目前最快的Python框架，其效率与NodeJS或Go类似。当速度和性能至关重要时，FastAPI 无疑是最佳选择。

对 ASGI 的本机支持

我们先提一下WSGI。它的全称是“Python Web Server Gateway Interface”，可以参考“PEP 3333”（https://peps.python.org/pep-3333/）。它是专门为 Web 应用程序和服务器之间的交互编写的 Python 标准。如果您使用过 PHP 或 Ruby，您可能会发现它更容易理解。 Flask 依赖于 Werkzeug，它是一个 WSGI 套件，因此 Flask 支持这个旧的 WSGI 标准，而不是 ASGI。

WSGI 的问题在于它无法利用异步来提高性能和效率。所以，Django通道开创了ASGI。它的全称是“异步服务器网关接口”，这是一个迭代的、几乎完全重新设计的标准。它提供异步服务器/应用程序接口并支持 HTTP、HTTP/2 和 WebSocket。与 WSGI 不同，ASGI 允许每个应用程序有多个异步事件。此外，ASGI 支持同步和异步应用程序。您可以将旧的同步 WSGI Web 应用程序迁移到 ASGI，也可以使用 ASGI 构建新的异步 Web 应用程序。

在下结论之前，我们先补充五个术语解释：

ASGI Toolkit：实现ASGI相关功能的库（如URL路由、Request/Response对象、模板引擎等）。本文主要指的是Starlette，它对应的是Flask的依赖Werkzeug。
ASGI Web 框架：实现 ASGI 规范的 Web 框架（如 FastAPI），而 Flask 和 Django 是实现 WSGI 的 Web 框架。这些框架专为开发人员编写应用程序而设计，具有易于使用的界面。开发者只需要根据自己的需求填写业务逻辑即可。早期的框架大多在内部实现ASGI工具包，而后来的框架通常会结合合适的工具包。例如，Flask 使用 Werkzeug（自己的），FastAPI 使用 Starlette（其他人的）。
Web应用程序：使用Web框架创建的应用程序就是Web应用程序。通常，Web 框架附带一个测试服务器，可以启动该服务器进行开发和调试。如果不关心性能和稳定性的话，你已经可以在浏览器中访问开发地址来访问这个应用了。
Web 服务器：现实世界比想象的更复杂。 Web应用部署到生产环境后，需要考虑请求负载均衡、静态文件服务、访问控制、反向代理等需求，同时对性能也有很高的要求。 Web框架内置的Web服务器根本无法满足这些要求，因此需要专门的Web服务器。目前Nginx是主流选择。
ASGI 服务器：ASGI 服务器充当 Web 服务器和 Web 应用程序之间的桥梁。 ASGI服务器也遵循ASGI规范，但其主要任务是满足转发请求的性能要求，因此它主要照顾ASGI的“G”（网关）部分。其代码对于开发者编写Web应用业务和路由逻辑并不友好。目前，最知名的ASGI服务器是Uvicorn，最初来自WSGI服务器Gunicorn的uvicorn.workers.UvicornWorker也是一个选择。这些是生产环境中的推荐用法。

以前WSGI的生产环境解决方案通常是Nginx Gunicorn Flask(Django)，而现在ASGI的生产环境解决方案是Nginx Uvicorn FastAPI。

还有一件事。从FastAPI的名称和介绍来看，很明显它是为了构建API服务而设计的。其实它的核心代码就是这样的。可以说，它不是一个传统的、完全自行实现的框架，而更多的是一个结合了各种框架优点的框架。它从一个空壳开始，组装必要且合适的组件。例如，它没有模板引擎。如果你确实需要用它来构建需要模板渲染的Web应用程序，你可以选择并组合你需要的模板引擎。当然，你也可以使用Starlette内置的Jinja2（是的，Flask也内置了）。

为什么说 Flask 已死

上述FastAPI的优点并不足以断定Flask已死。那么，我为什么持有这样的观点呢？主要取决于开发者和用户的受欢迎程度。

这里的“受欢迎程度”是相当主观的。我能想到的指标如下：

社区活动(https://github.com/pallets/flask/issues)：以项目的 issues 和 pull requests 数量为例。 Flask 只有个位数，这与 FastAPI 完全不同。这其实从侧面反映出该项目已经不再活跃了。如果项目活跃的话，老用户会有更多的需求。如果他们停止提出问题，就意味着他们已经离开了。而新用户肯定会遇到各种各样的问题。即使有详细的文档，仍然应该有很多用户来提问和贡献代码。没有这种情况说明用户较少。
讨论热度：即博客文章、Stack Overflow 等网站上的查询和讨论的热度。很明显，现在写 Flask 的人很少了。
开发迭代频率(https://github.com/pallets/flask/pulls)：从commit记录可以看出，Flask只有一名维护者，偶尔修复一些bug，没有什么主要功能发展。
关键人物的影响力：Flask背后的关键人物，项目发起人，早已不再参与该项目。根据项目贡献记录，Armin Ronacher 上次为该开发做出贡献是在六年前。

在我看来，所有这些情况都表明 Flask 的鼎盛时期已经过去，FastAPI 是后起之秀。

最后介绍一下部署Flask/FastAPI的理想平台：Leapcell。

Leapcell是专为现代分布式应用程序设计的云计算平台。其按需付费的定价模式确保没有闲置成本，这意味着用户只需为他们实际使用的资源付费。

Is Flask Dead? Is FastAPI the Future?