请不要把 Flask 和 FastAPI 放到一起比较

[greyli]

https://greyli.com/flask-fastapi/

TLDR: FastAPI 是基于 Web 框架 Starlette 添加了 Web API 功能支持的（框架之上的）框架，而 Flask 是和 Starlette 同类的通用 Web 框架，两者不应该放到一起比较。

文中观点或有偏颇，欢迎指正和补充。

[renmu123]

1. 如果一个框架看着像 web 框架，用着像 web 框架，那是不是 web 框架?
2. 如果有一个基于 flask，pydatic 和 openapi 也开箱即用的框架（我不知道现在有没有出现，很久没写 flask 了，但如果有应该会有挺多人买单），那么它能不能和 flask 做比较吗?我个人觉得是可以的。

ps：某乎有不少这样的文章，大部分都是为他们的公众号引流的。

[mekingname]

我是《用它 5 分钟以后，我放弃用了四年的 Flask 》的作者。感谢博主的澄清。

其实我写这篇文章的用意，并不是对比两个框架谁好谁不好。我想表达的就是我用 FastAPI，用起来很爽很舒服。仅此而已。

就像博主举的例子，苹果和橙汁。确实，苹果和橙汁都不是同一类东西。但是，这不妨碍橙汁比苹果味道好，所以我喜欢喝橙汁，不喜欢吃苹果。我并不关心橙汁是基于什么做出来的，也不关心做橙汁的橙子与苹果谁好谁坏。我只关心最终拿给享用的东西，谁的味道好。

以后如果有一个框架基于 Flask，并且有比 FastAPI 更好的用户体验，那我也会毫不犹豫转过去的。

[greyli]

@renmu123

> 1. 如果一个框架看着像 web 框架，用着像 web 框架，那是不是 web 框架?

这个问题我没理解。你可以说 Flask 和 FastAPI 都是 Web 框架，但是它们的性质是完全不同的。

> 2. 如果有一个基于 flask，pydatic 和 openapi 也开箱即用的框架（我不知道现在有没有出现，很久没写 flask 了，但如果有应该会有挺多人买单），那么它能不能和 flask 做比较吗?我个人觉得是可以的。

文中提到的 APIFlask 算一个（不过是基于 Marshmallow 而不是 Pydantic ）。基于 Flask 的框架和 Flask 本身比较有什么意义呢？「骑着自行车的我」和「我」进行比较？

[greyli]

@mekingname 很抱歉把你的文章挑出来作为反面示例，希望没有冒犯到你。

苹果和橙汁可以比较，但这种比较是不合理不公正的（这是我想来澄清这件事的主要原因）。成年人和小孩子当然可以比武，但是这种比武不是建立在对等实力上的。我个人认为推介 FastAPI 更合理的行文方向有两种：单独介绍 FastAPI 的特性（不用和谁比较）；介绍 Flask 搭配某些 REST API 扩展相对于 FastAPI 的劣势（公平合理）。

> 以后如果有一个框架基于 Flask，并且有比 FastAPI 更好的用户体验，那我也会毫不犹豫转过去的。

欢迎试试 APIFlask，不过它还是个新项目，或许用户体验并不优于 FastAPI 。

[charlie21]

@mekingname #2
“苹果和橙汁都不是同一类东西。但是，这不妨碍橙汁比苹果味道好，所以我喜欢喝橙汁，不喜欢吃苹果”
盲猜您一定是 Apple 产品用户

[joApioVVx4M4X6Rf]

@greyli 你最近在用 python 吗?看了你的书入门的 web，结果发现现在 python 很多都是做内部系统了。

[superrichman]

我把 ae86 的引擎换成赛车的就不让我和你的原厂五菱宏光比赛了？

[mekingname]

@greyli 没问题，欢迎技术交流。

> 成年人和小孩子当然可以比武，但是这种比武不是建立在对等实力上的。

Flask 其实年龄比 Fastapi 更大吧。我们是不是能这样认为：Flask 是一个普通的成年人，Fastapi 是一个经过基因增强的变种小孩。我们发现这个小孩比成年人还厉害。这样对比似乎就合情合理了吧？变种小孩跟普通小孩对比，岂不是更不公平？

> 我个人认为推介 FastAPI 更合理的行文方向有两种：单独介绍 FastAPI 的特性（不用和谁比较）；介绍 Flask 搭配某些 REST API 扩展相对于 FastAPI 的劣势（公平合理）。

是的，这样介绍确实能更公平全面讲述 FastAPI 的特性。我以后的文章注意一下。

[LeeReamond]

有一说一，主题说的倒是没错，不过辨析的意义是什么呢，又一个 python 版的回字四种写法吗

[greyli]

@mekingname 我只是打个比方说明这是一种不对等关系……

[greyli]

@LeeReamond

> 有一说一，主题说的倒是没错，不过辨析的意义是什么呢，又一个 python 版的回字四种写法吗

委婉的说，是想澄清一个误解。直白的说，是因为利益相关（见文中备注）。

[renmu123]

@greyli 我的意思多数最终用户（程序员）不会那么在意概念，能动的轮子就是好轮子。严格来说，我认为你说得肯定是没有问题的。
我们可不可以说“骑着自行车的我”比“我”就速度来说更快。用框架的功能来说就是，某个功能更加好用

[greyli]

@v2exblog 做内部系统不也挺好，其他语言流行再学就是了。有一个语言 /框架作为基础再学其他语言 /框架也会容易得多。

[LeeReamond]

@greyli 不是很清楚开源项目的维护者本身如何产生利益相关，不过 io 复用为本身运行效率低下的 io 解决了大问题，本身大势所趋，fastapi 全是其中一个比较圆的轮子，且营销较好。我觉得你既然还在维护旧框架，本身是逆潮流而行，各方面不被理解也是正常的

[greyli]

@LeeReamond 我指的是我作为维护者，不希望其他人用这种不合理的对比来让用户对 Flask 产生误解。我并不否认 FastAPI 各方面很优秀。

[abersheeran]

@LeeReamond 上了 greenlet 优化的 flask 不比 fastapi 慢。解决 IO 问题又不是只有 asyncio 可以用。

https://web-frameworks-benchmark.netlify.app/result?l=python

[abersheeran]

说起来我司给我的最新任务是给他们写一个基于 bottle 的 template 。虽然我觉得上 asyncio 没什么成本（因为是一行代码都没有的新项目）但是大部分人在性能需求不高的时候还是更倾向于同步写法。

[Sh1nes00n]

我最初选用 fastapi 是因为路由写法`app.get()`和取参`def hello(param: int = 0)`，看到 flask2 即将支持这种路由感到非常欣慰。

还有尬吹性能的，还是那句话，没多少项目能活到拼性能那天，真到那天了，资本会给你最好的解决方案。

「在每个 commit 信息里都加上 emoji 并不可爱」
我看到这种操作方式后，在自己的 private repo 里也尝试了下，提交几个 commit 后发现，除了 feature 里增加🎉让我感到快乐外，普通 commit 添加表情（像😘）感觉太傻 x 了

[wdhwg001]

FastAPI/Starlette 实际用起来确实有不如 Flask 方便的地方，比如必须显式传递上下文，并且没有足够的生命周期管理。并且用它开发的时候，经常需要读两个文档和翻两份源码，而且 FastAPI 还经常导入 Starlette 的内容之后什么都不做，或者重写一份 Starlette 里已有的文档，这使得溯源过程变得更艰难了。

但说实话，我还是看好 asyncio 的未来的，无栈协程的性能问题其实应该怪 Python，而不是怪框架。

[LeeReamond]

@abersheeran 手机打字有些问题，我那句话本来想打的是 io 复用对于本身运行效率低的 python 意义重大，打错字了手机没发现，意思变得很奇怪。我觉得跑分这个事吧，毕竟 io 的大头还是在系统调用，跑分有不同结果也正常，但毕竟单线程下 io 复用在工业界广泛应用是大家用脚投票投出来的。

flask 本身是个很优雅的框架，那它也就要承受优雅的反作用，你只能无奈说现在大家不是很接受这个