Flask！Flask！你怎么了？Flask~Flask~你不能死呀！我跟你相依为命、同甘共苦了这么多年，何况我的书还没有写完，想不到今天白发人送黑发人……

咳咳，说回正题，2021 年我写过一篇《请不要把 Flask 和 FastAPI 放到一起比较》。不是同一个等级的框架拿到一起比较没有意义。这篇《Flask 已死，FastAPI 是未来》从一开始的标题就是错的。

除了比较上的问题，上一篇文章里最后提的问题现在有答案了吗？

各种对比文章贴出来的 hello world benchmark 对于开发生产应用来说有多大的意义？这里的 benchmark 背后有没有任何的 hacky？异步是否等同于高性能还是要看情况？框架本身的性能在一个请求处理流程中占多大的影响？asyncio 的生态怎么样？

同时我也指出了一些 FastAPI 的问题——现在 FastAPI 营销至上的项目运作方式改变了吗？

从长远看这些大都是一些临时问题，而且 FastAPI 作者已经开始全职开发开源项目，这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI，吹捧并不能让一个东西变得更好，参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好，也期待看到有更多优秀的 Python 框架出现，但我不喜欢过度炒作、盲目的吹捧和错误的对比。

如果一个人即没有深入了解 Flask，也对 FastAPI 的整体状况一知半解，然后突然跳出来写了一篇《Flask 已死，FastAPI 是未来》，他的目的是什么？炒作啊，朋友。标题党也就罢了，到处都是逻辑漏洞和事实错误这也行？

精彩片段赏析

前两天在 Twitter 上对这篇文章发了一点想法。大概是我的语言能力退化，导致很多人没看懂我的反讽和调侃……所以还是好好说话，摘评几条原文的内容：

其实我这篇文章，也可以叫做「Django和Flask之死」，但是在框架应用场景角度来说Flask和FastAPI对比更合适，而Django直接和FastAPI相比有一些差别。在一些商业场景(例如CMS)Django依然是首选，而Flask(甚至FastAPI)看起来更像个「玩具」，所以Django短时间不会被取代(Flask这些年不是也是没取代的了嘛)。
Django REST Framework(DRF)
Django主旨是为了在后端生成 HTML，而不是创建现代前端（如 React、Vue.js ）或与其通信的其他系统使用的 API。所以FastAPI其实和Django REST Framework直接对标，它们主要场景都是构建 Web API，但是名字上也可以看出来，DRF还是依托于Django框架，所以缺点一样。

既然作者能看出来 Django 和 FastAPI 有差别，也了解「FastAPI其实和Django REST Framework直接对标」，那么就看不出来 Flask 和 FastAPI 在框架应用场景角度有差别？所以为什么不用 APIFlask 这种和 FastAPI 对标的框架，而是挑了 Flask？

Flask本来的优点是灵活性和极简主义，但这意味着很多很多组件需要自己造，这个要不然需要公司够大专门有开发者开发和维护，要不然得个人能力极强，否则插件很难达到生产级别，这就造成Flask的第三方插件质量层次不齐，且无法保证长期维护。就像我上面说的那些库，现在来看，其中已经很多不再维护了。

这点蛮中肯，Flask 扩展的质量和维护状态确实参差不齐，这也是为什么我要发起濒危 Flask 扩展拯救计划并创建这个 Flask 扩展状态监控项目。那请问 FastAPI 呢？首先 FastAPI 是否有这么多「FastAPI 扩展」可用？其次 FastAPI 的第三方插件就不会出现这些问题？说到底这是所有开源项目和社区生态都会遇到的问题。

所以即便是今天，你想用Flask构建一个API服务，还是要东拼西凑各个组件，其中某些组件有些没及时更新的地方要自己动手解决，这对于老手来说还好，对于新人来说很痛苦，尤其是你想要应用现在最新的实践方案和理念，只能望而兴叹。

首先作者了解 Flask 和 FastAPI 相比，后者的主要场景是「主要场景都是构建 Web API」，接着又说 Flask 生态构建 API 需要东拼西凑。听起来不太对劲？

另外 Flask 生态中类似 FastAPI 这种提供 API 整体解决方案的框架都被作者忽略了？随便列几个：

• APIFairy
• APIFlask
• Connexion
• Eve
• Flask-RESTX
• Flask-Smorest
• Flask-Rebar
• SpecTree

东拼西凑就一定是缺点？不熟悉这些工具的人选择打包方案，熟悉的人选择自己组装，这有什么问题吗？

这个时候Flask并不想接受改变，社区迟迟的不加入aio的支持，另外Flask原作者也去写rust了，把项目交给了2个维护者（现在只剩一个人了)。

到这里文章就开始有些不对劲了，喜剧/戏剧效果逐渐增加……Flask 开始被拟人化了。Flask 是谁？是谁要求改变？Flask 说了啥表示不想改变？

Flask 作者把项目交给了 2 个维护者？现在只剩一个人了？！Flask 真的好惨……可是这些事情都是什么时候发生的？虽然我最近两年开始工作已经没怎么给 Flask 提交代码，不知道哪天被踢出群聊。但是至少我从 18 年到现在一直是 Flask 的维护者，这些事情我怎么一点都不知道？

在Flask的那个时代，代码执行是单线程、同步的，这意味着要依次处理请求，前一个请求完成前，其他请求消耗在等待 I/O 操作上。而asyncio是最好的解决方案，它让I/O成为异步操作，无需等待任务完成即可获取任务结果并继续处理其他任务请求。

好奇 Flask 的那个时代是哪个时代呀？听起来像是妈妈在讲小时候的故事呢。Flask 2.0 已经添加了有限的 async 支持。Quart （Flask 的 ASGI 实现）已经合并到 pallets 组织，作者正在推动 ASGI 支持的 Flask。这些都是这个时代的 Flask 在发生的事情哦。

而FastAPI天生支持并发和异步代码，代码写对了就可以在效率上达到极致，所以它被认为是目前最快的Python框架，效率和NodeJS或Go接近。当速度和性能至关重要时，FastAPI 是最佳选择。

嗯，这个我无从反驳。你说快就是快，宇宙最快 Web 框架。

另外由于集成了Pydantic，所以非常容易在项目中添加ORM（如SQLAlchemy），从请求中获得的对象可以直接传递到数据库，因为已经做过数据验证。反之亦然，可以将从数据库获取的对象直接返回。
相对的，Flask这方面的缺失的。

完蛋，Pydantic 对 Flask 发起了单方面安装制裁。当你在 Flask 项目里试图引入 Pydantic 的时候，就会出现安装错误“Warnning: Pydantic is strictly forbidden to installed into a Flask project. Your behavior has been reported to PAFAFC (Pydantic and FastAPI and friends Committee).”

再补充一点。FastAPI无论看项目名字还是介绍都能感觉出来它是用于构建API服务的，事实上FastAPI自己的核心代码也确实是这样的，可以说它不是一个传统的、完全自己实现的框架，它更像是一个集各家之长的框架，从一个空壳开始，把需要的、适合的组件组装起来。例如它没有模版引擎，如果你确实需要用它实现一个web应用要渲染模版，你可以再组合你想要的选择，当然还可以用Starlette内置的Jinja2（是的，也是Flask内置的）。

作者对于 Flask 和 FastAPI 两者定位不同的认识真是越来越清晰了呢。不过「组合我想要的选择」不就变成前面说的 Flask 那样东拼西凑了嘛，不好。还有就是 FastAPI 为啥要在介绍模板引擎的文档里让我安装 Jinja2 呢？看来「相对的，FastAPI这方面是缺失的」。

上面提的是FastAPI的优势，但是也不能说明Flask已死，我为什么会这么觉得呢? 主要还是看开发者和用户的人气。

重头戏来了，下面终于到了对于「Flask 之死」的凄惨景观的详细描写（注：这几点后来作者看到了我在 Twitter 上发的东西又自己做了补充和修改。这里我引用的是原文）。

1. 社区活跃度。例如项目的Issue和Pull Request数量，Flask都是个位数，和FastAPI相比根本不是一个水平。这其实侧面证明项目不再活跃，因为如果活跃的话，老的用户会有更多需求，它们不来说明已经离开，而新的用户意味着有各种问题，文档即便足够全，其实我们要知道还是会有很多用户来提问和贡献代码的，没有就说明用得少。

如果你经常参与开源项目或是自己开发了开源项目，通常会了解到，一个流行的项目想要把所有的 issue 和 pull request 都处理掉是很难的事情。而 Flask 能做到这一点反而是维护团队的努力尽责和项目本身足够成熟的体现：

以及对 issue 和 pull request 快速响应的体现：

如果你想知道有多少人在用 Flask 和 FastAPI，有两个参考数据，一个是 GitHub 上开源项目的用户数量统计。这些可以在两个项目的 GitHub 主页直接看到。

FastAPI：

Flask：

另一个数据是 PyPI 下载量，这个可以在 PyPI Download Stats 上看到。

FastAPI：

Flask：

另一方面，不同的项目对 issue 的使用策略是不同的。有的使用自己的 issue tracker，有些鼓励用户来提问。Issue 和 pull requests 不仅不能用来表示项目活跃度，过多的数量反而能说明一个项目的维护状况堪忧。堆积的 PR 对于用户和开发者来说都是灾难。以 FastAPI 为例，你看看现在的 PR 列表里都是什么？项目不如改名叫「FastAPI 文档大全」好了。你觉得这样会让提交代码贡献，修复 bug 的人有很好的体验？

FastAPI 有不少 issue 在建议作者创建开发团队，摆脱当前这种低效的维护模式。类似的抱怨有很多，我不想去翻历史，这里仅以置顶 issue 里的一则回复举例：

评论中提到的是这个 PR。一个 bug 在 2022 年就有人试图修复，但是到现在都没有被处理。而且报告相关 bug 的 issue 已经被转换成讨论。最后一条是用户在建议把这个讨论转换回 issue：

没错，FastAPI 本来有几百个 issue（好活跃，对吧），某个时间点被批量转换为讨论，谁知道里面有多少是没有被处理的 bug report。谁知道这 646 个 PR 里有多少是需要被优先处理的 PR。我在 2020 年也提议把文档翻译放到单独的仓库，后来这个 issue 也被转成讨论了。到现在贡献者依然被这个问题困扰：

2. 讨论度。也就是博客文章，Stackoverflow等网站咨询和讨论的热度，其实可以感受到，已经没什么人写Flask相关的内容了。

作者写文章是可以随口就来的？博客文章不好统计，那么以 Stack Overflow 来看。抛开问题总数量，因为两个项目创建时间不同。但就提问频率，以上次发推文和现在两次截图的数据来看，和 Flask 相关的问题都创建的更频繁。

FastAPI：

Flask：

3. 开发迭代的频率。翻一下commits，可以看到Flask只有一个维护者会偶尔修修bug，没有什么大的功能特性开发。

开发迭代的频率和活跃度也是作者强行建立的联系，不过结合 FastAPI 的运作方式，两位作者倒也是「双向奔赴」了。「偶尔修修bug，没有什么大的功能特性开发」有什么问题吗？这就是维护者应该做的事情，大的功能特性又不是每天都有。而且作者是不是没有看 FastAPI 的 commits 历史？你肯定猜不到三千多个 commits 里有一千多是 bot 在更新 changelog。再猜猜 FastAPI 最新一个 release 都有哪些新功能？11 个改动里有 5 个是在更新 README 上的赞助商列表哦：

4. 灵魂人物的影响力。Flask的灵魂人物，也就是项目的发起人其实早就不再参与项目了，搜一下项目贡献记录可以看到Armin Ronacher上次参与开发已经是6年前了。

这条实在不知道说什么好。我创建了项目我就得绑死在项目上直到生命最后一刻是吗？引用一下我在 Twitter 上的回复：

开源项目一定不要创建 GitHub org，项目再流行也要放在自己的账号下。不要成立什么开发团队，PR 要自己慢慢 review，用户抱怨多了，你自然知道哪个 PR 比较重要。还有就是用自己的账号或头像来设置 bot，这样即使你哪天兴趣转移了，用户会以为你一直在参与。斯人已去，灵魂犹在。

我真的佩服 FastAPI 作者这一招用自己的账号来作为 bot，用户以为你在活跃，而这个 PR 哪天能够被 merge 还要多烧几炷香：

一边说自己忙得不行，一边又坚持把项目放在自己个人账号下，坚持自己 review PR。这就是灵魂人物？

后记

终于写完了。没想到只是偶然在一台没有屏蔽推荐首页的电脑上打开了知乎，最后要浪费这么多时间和精力。我想肯定会有人看了开头就急着评论，说「FastAPI 如何好用」或是「Flask 如何不好用」甚至是「Python 不如 XXX」。这些都是离题的讨论，我不完全否认这些观点，也并没有谈及这些。这篇文章只有两个目的：

• 强调不应该把两者放到一起比较
• 指出那篇「引战文」中的错误观点和事实偏差，顺便指出一些 FastAPI 的问题

对于程序员来说，你可以使用任何框架，你也可以使用任何编程语言。程序员不就是要随时接受改变，随时学习新的东西吗？没人要你一辈子只能用 Flask 或是 Python。另一方面，即使别人都用 FastAPI 了，我用 Flask 又会怎么样？工具而已，只是按照需要做出适当或喜欢的选择。但是你起码要看一看文章再发表评论，而且也不用看到什么观点就相信什么观点（尤其是没有论据、结论先行的文章）。

同时建议 FastAPI 推介者保留一点体面。新事物的建立不一定要踩在已有事物的坟墓上。挑起对立只会导致 Python 社区的混乱。最后再引述我在上一篇文章的想法作结：

从长远看这些大都是一些临时问题，而且 FastAPI 作者已经开始全职开发开源项目，这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI，吹捧并不能让一个东西变得更好，参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好，也期待看到有更多优秀的 Python 框架出现，但我不喜欢过度炒作、盲目的吹捧和错误的对比。

相关链接

• 本文在知乎上的讨论

• 大会网站：https://gotc.oschina.net/
• 议题链接：https://gotc.oschina.net/forum/lists/1/32
• 报名链接：https://www.bagevent.com/event/7330325

我的演讲主题是《基于 Python 的 OpenAPI 实践》，介绍如下：

OpenAPI（原 Swagger）是一个流行的 REST API 描述规范，围绕它有许多非常实用的 Web API 开发工具。而 Python 是一门流行的编程语言，使用它可以非常高效地开发 Web API。这个议题将会以 OpenAPI 的入门介绍开始，探索如何在流行的 Python Web 框架中实现 OpenAPI 支持，并在最后介绍一些现有的解决方案和工具。

这个演讲基本上是正在写的《Python Web API 设计与开发》第八章的内容概括 + 开发 APIFlask 的一些想法 + 周边项目（FastAPI、Connexion 等）研究总结。暂定大纲为：

• OpenAPI 介绍
• Code-first 模式（从 Python Web 框架代码生成 OpenAPI spec）
• Design/API-first 模式（从 OpenAPI spec 生成 Python Web 框架基础代码）

我的演讲在深圳站第一天分会场「编程语言艺术」专题论坛。如果你感兴趣的话，欢迎来听；如果对演讲内容有任何建议，欢迎提出。

The war has begun. Let’s end the war between Flask and FastAPI.

去年在知乎上看到一篇文章，后来想找却找不到了，最后通过关键词「5 分钟」和「四年」在掘金上找到了原文——《用它5分钟以后，我放弃用了四年的 Flask》。作者先是给出了一个手动用 if 验证请求数据的 Flask 视图函数：

@app.route('/insert', methods=['POST'])
def insert():
    info = request.json
    name = info.get('name', '')
    if not name:
        return {'success': False, 'msg': 'name 参数不可省略，不可为空！'}
    age = info.get('age', 0)
    if not isinstance(age, int):
        return {'success': False, 'msg': 'age参数不是数字！'}
    age_after_10_years = age + 10
    msg = f'此人名叫：{name}，10年后，此人年龄：{age_after_10_years}'
    return {'success': True, 'msg': msg}

然后给出了一个使用 Pydantic 编写数据模型类 + FastAPI 路径操作函数的代码：

class People(BaseModel):
    name: str
    age: int
    address: str
    salary: float
    
@app.post('/insert')
def insert(people: People):
    age_after_10_years = people.age + 10
    msg = f'此人名字叫做：{people.name}，十年后此人年龄：{age_after_10_years}'
    return {'success': True, 'msg': msg}

通过这两段代码进行对比，文章作者得出结论「我用了 Flask 四年，但在使用了5分钟 FastApi 以后，我决定以后不再使用 Flask 了」。你确定你用了四年的是 Flask 而不是 Flash？在此后的很长一段时间里，经常看到类似的对比和结论，所以我打算用这篇文章来澄清这个非常普遍的误解。如果看到有人把 Flask 和 FastAPI 放到一起比较，请把这篇文章的链接丢过去。

利益相关：笔者系 Flask 维护者和 APIFlask 作者。本文观点仅代表个人看法，与 Pallets 团队无关。

为什么 Flask 和 FastAPI 不能放到一起比较？

我在此前介绍 APIFlask 的文章里一开始就提到过这件事情：

经常看到有人把 FastAPI 和 Flask 放到一起比较，但是却没有意识到这完全是两种东西——前者是基于 Web 框架 Starlette 添加了 Web API 功能支持的（框架之上的）框架，而后者是和 Starlette 同类的通用 Web 框架。你怎么能让小明和骑电动车的小军赛跑然后还夸小军好快好强？

前两天看了 Reddit 上 Flask 2.0rc 帖子下的很多回复，预感到在 Flask 2.0 发布后在中文网络上也许会出现许多类似的问题和讨论，所以想着还是值得单独写一篇文章来谈这件事。

受那个 Reddit 主题里某个评论启发，想到一个更好的比喻： Flask 和 FastAPI 就像是苹果和橙汁。你不能把苹果和添加了更多蔗糖和添加剂的橙汁放在一起比较哪一个更甜。苹果（Flask）应该和橙子（Starlette）比较，橙汁（FastAPI）当然也应该和苹果汁（基于 Flask 的 Web API 框架）进行比较。也就是说，Flask 是一个通用型框架，和 FastAPI 依赖的 Starlette 一样，而 FastAPI 是添加 Web API 支持的二次框架。因此，Flask 应该和 FastAPI 所依赖的 Starlette 进行比较，而 FastAPI 应该和基于 Flask 的 Web API 框架进行比较。

同理，FastAPI 也不能和 Django、Tornado、web2py、Bottle、CherryPy、Pyramid、Sanic 等通用型 Web 框架比较。

更合理的比较对象是什么？

既然「FastAPI 应该和基于 Flask 的 Web API 框架比较」，那么合适的比较对象有哪些？Flask-RESTX、Flask-Rebar、flask-apispec、flask-smorest、Flask-RESTful、APIFairy 这些虽然试图做成框架，但在具体实现上仍然是 Flask 扩展，所以真正公平合理的比较对象是：

• Eve
• Connexion
• APIFlask

这三个框架都是基于 Flask 实现的 Web API 框架。不过 Eve 没有内置 OpenAPI 支持，而 Connexion 是一个 Spec-First 框架，也就是 OpenAPI spec 优先（先编写 spec，然后生成项目基础代码进行开发）的框架。因此，尽管 APIFlask 只是一个刚发布没多久的实验项目，但它是最适合和 FastAPI 进行比较的项目。

FastAPI 和 APIFlask 有着同样的组成结构，都是作为一层胶水粘起来一个 Web 框架和一个数据序列化/验证库，然后加一点 Web API 功能支持：

• FastAPI = Starlette + Pydantic
• APIFlask = Flask + Marshmallow

在主要功能上也有很多交集：

• 自动反序列化和验证请求数据，自动生成错误响应
• 自动格式化和序列化响应数据
• 自动生成 OpenAPI specification 文件
• 自动生成交互式 API 文档

当然，相对于发布已经三年的 FastAPI，APIFlask 还只是一个三个月大的新项目，还有很多地方需要改进和完善。如果你对 APIFlask 感兴趣的话，可以在这篇文章了解详细介绍或是在它的 GitHub 仓库查看源码。

为什么会有这样的误解？

为什么会有那么多人把 FastAPI 和 Flask 放到一起比较？在我看来有三个原因：

首先是 FastAPI 采用了和 Flask 类似的装饰器路由，很容易让人联想到 Flask。

二是 FastAPI 没有给它的项目构成做足够的说明。如果 FastAPI 在其介绍的第一句就加上「based on Starlette and Pydantic」而不是放到 Requirements 部分才提及，这样也许会让 Starlette 和 Pydantic 获得更多应有的关注，也就不会有这么多人拿 Flask 和它比较。

再就是 FastAPI 的推介者对 FastAPI 了解的不够多。不清楚它的项目结构，自然就不了解它和其他 Web 框架的区别。而介绍时为了带来足够的吸引力，推介者常常选择拉上和用户量足够大的「竞品」进行对比这种方式，所以才会有大量类似本文开头提到的那种文章。这些文章甚至完全没有提及 Starlette 和 Pydantic，只是一味强调「这是一个超高性能的、碾压 Flask 的框架」。

FastAPI 不是银弹

FastAPI 只是说它能把「功能开发速度提升约 200% 至 300%」，距离十倍还差了一些，自然不能算是银弹。但是这两年看到了很多对 FastAPI 的盲目吹捧，仿佛 FastAPI 就是完美的解决方案。这也许都要归功于 FastAPI 在其 README 和文档里「大胆」的措辞和承诺以及不厌其烦的特性介绍。举例来说，如果它只是说「Very high performance, it is comparable to some frameworks in Go and NodeJS」，那么用户也许就会认为「和 Go/NodeJS 有一拼」，但是说成「Very high performance, on par with NodeJS and Go」，那么用户就会想「和 Go/NodeJS 不相上下」（以至于中文翻译是「可与 NodeJS 和 Go 比肩的极高性能」），这当然会带来一些争议。再比如，如果只是说「double or triple the development speed」，那么用户大概会想「效率还不错」，但是它用了「Increase the speed to develop features by about 200% to 300%」，数学不好的用户就会惊呼「哇，提高 30 倍开发效率」。同时这种营销带来的狂热用户，也很容易被煽动去给 Python Steering Council 施加压力——在 Python 3.10 快要发布的时候突然跳出来要求撤销一个 PEP。

这种营销至上的项目运营方式带来的直接后果是糟糕的维护状态。FastAPI 似乎在慢慢变成一个翻译项目，在代码里的文档字符串都还没写的情况下，其用户文档就已经开始扩展到十几种语言。而这十几种语言的翻译和项目源码都放在同一个仓库里，这导致所有开启的近 300 个 PR 里有过半是翻译。issue tracker 和 discussion 不做区分的使用，这导致所有开启的近 600 个 issue 里有九成是提问）。我在此前创建过一个 issue 来反馈这个问题，但并没有得到回应。另外凭个人喜好来说，在每个 commit 信息里都加上 emoji 并不可爱。而每一个 commit 都要触发 bot 更新 changelog，带来的是一份丑陋的 commit 历史（所有 commit 里有三分之一是在更新 changelog）。这些也许是发展社区或是让项目看起来很活跃的有效方法，但很显然这带来的是建立在混乱之上的虚假繁荣。

另外，许多推介文章都会在最后贴出来一张 benchmark 截图来证明 FastAPI 有多么 fast，但是完全不会提及的是：贴出来的 benchmark 对于开发生产应用来说有多大的意义？这里的 benchmark 背后有没有任何的 hacky？异步是否等同于高性能还是要看情况？框架本身的性能在一个请求处理流程中占多大的影响？asyncio 的生态怎么样？

从长远看这些大都是一些临时问题，而且 FastAPI 作者已经开始全职开发开源项目，这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI，吹捧并不能让一个东西变得更好，参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好，也期待看到有更多优秀的 Python 框架出现，但我不喜欢过度炒作、盲目的吹捧和错误的对比。

P.S. Flask 2.0 版本即将发布

顺便说一句，Flask、Werkzeug、Jinja 等 Pallets 项目都将在 5 月 11 日（PyCon 开始）之前发布下一个主版本，主要包含下面这些新特性（完整变动见 changelog）：

• Flask、Werkzeug 和 Click 添加了 type hints
• Flask 实现了有限的 async/await 支持
• Flask 支持嵌套蓝本
• Flask 添加了快捷版本的 route 装饰器（即 @app.get、@app.post 等）
• Flask 支持在视图类上使用 route 装饰器（我前两天刚提交了一个 PR 来实现这个功能，暂时不确定是否会被合并，在这先提前说一下 :p）
• Werkzeug 的 multipart 解析性能大幅提升

你可以使用下面的命令安装 Flask 2.0.0rc 版本进行测试：

 $ pip install --pre flask

欢迎反馈 bug 和提改进建议。关于 2.0 版本的详细介绍将会在发布后另外撰文说明。

延伸阅读

• 用它 5 分钟以后，我放弃用了四年的 Flask
• 用它 5 分钟以后，我放弃用了四年的 FastAPI
• Ignore All Web Performance Benchmarks, Including This One
• I’m not feeling the async pressure
• FastAPI – Benchmarks
• 在 V2EX 上的相关讨论
• 在 V2EX 上的后续讨论
• 在知乎上的相关讨论

• 主页: https://apiflask.com
• GitHub: https://github.com/greyli/apiflask
• Twitter: https://twitter.com/apiflask

APIFlask 在 Flask 的基础上添加了更多 Web API 相关的功能支持，核心特性包括：

• 更多方便的装饰器，比如 @app.input()、@app.output()、@app.get()、@app.post() 等等
• 自动反序列化和验证请求格式，当请求数据不符合模式类要求时，会自动生成包含错误详细信息的错误响应（基于 Webargs）
• 自动格式化和序列化响应数据，在定义好响应模式后，你可以直接在视图函数返回一个模型类对象，或是返回字典（基于 Marshmallow）
• 自动生成 OpenAPI Specification 文件，你可以把这个文件导入到 API 调试工具或是用来生成客户端代码（基于 APISpec）
• 自动生成交互式 API 文档，并自动为蓝本和视图设置对应的标签分类（基于 Swagger UI and Redoc）
• 自动为 HTTP 错误生成 JSON 格式的错误响应

下面是一个最基础的示例程序：

 from apiflask import APIFlask, Schema, abort
 from apiflask.fields import Integer, String
 from apiflask.validators import Length, OneOf
 ​
 app = APIFlask(__name__)  # 可以使用 title 和 version 参数来自定义 API 的名称和版本
 ​
 pets = [
     {
         'id': 0,
         'name': 'Kitty',
         'category': 'cat'
     },
     {
         'id': 1,
         'name': 'Coco',
         'category': 'dog'
     }
 ]
 ​
 # 定义一个请求数据模式类
 class PetInSchema(Schema):
     name = String(required=True, validate=Length(0, 10))  # 可以使用 description 参数添加字段描述
     category = String(required=True, validate=OneOf(['dog', 'cat']))
 ​
 # 定义一个响应数据模式类
 class PetOutSchema(Schema):
     id = Integer()
     name = String()
     category = String()
 ​
 ​
 @app.get('/pets/<int:pet_id>')
 @app.output(PetOutSchema)  # 使用 @output 装饰器标记响应数据模式
 def get_pet(pet_id):
     if pet_id > len(pets) - 1:
         abort(404)
     # 在真实程序里，你可以直接返回 ORM 模型类的实例，比如
     # return Pet.query.get(1)
     return pets[pet_id]
 ​
 ​
@app.patch('/pets/<int:pet_id>')
@app.input(PetInSchema(partial=True))  # 使用 @input 装饰器标记请求数据模式
@app.output(PetOutSchema)
def update_pet(pet_id, json_data):  # 通过验证后的请求数据字典会注入到视图函数，默认参数名为 json_data
    if pet_id > len(pets) - 1:
        abort(404)
    for attr, value in json_data.items():
        pets[pet_id][attr] = value
    return pets[pet_id]

P.S. 你也可以使用类视图（class-based views），具体示例见这里。

如果你想在你的电脑上运行这个示例，可以先用下面的命令安装 APIFlask（需要 Python 3.7 及以上版本，Flask 1.1 及以上版本）：

Linux 和 macOS:

 $ pip3 install apiflask

Windows:

 > pip install apiflask

安装完成后把上面的代码保存到文件 app.py，然后执行下面的命令运行程序：

 $ flask run

现在你可以在浏览器访问 http://localhost:5000/docs 查看基于 Swagger UI 自动生成的交互式 API 文档：

或者访问 http://localhost:5000/redoc 查看基于 Redoc 生成的 API 文档：

访问 http://localhost:5000/openapi.json 可以获取自动生成的 OpenAPI spec 文件。

这个示例程序的完整版本可以在 https://github.com/greyli/apiflask/tree/master/examples 看到。如果你想了解更多用法，可以阅读文档中的基本用法一章（目前只有英文）。

APIFlask 只在 Flask 之上做了轻量级包装，所以你实际上仍然是在写一个 Flask 程序，所有 Flask 的特性都完全兼容。你只需要记住下面两处不同点：

• 创建程序实例的时候使用 APIFlask 类（from apiflask import APIFlask）。
• 创建蓝本实例的时候使用 APIBlueprint 类（from apiflask import APIBlueprint）。
• 使用 apiflask.abort() 函数返回 JSON 格式的错误响应。

以下面的 Flask 程序为例：

 from flask import Flask, request, escape
 ​
 app = Flask(__name__)
 ​
 @app.route('/')
 def hello():
     name = request.args.get('name', 'Human')
     return f'Hello, {escape(name)}'

迁移到 APIFlask 只需要改动两行代码：

 from apiflask import APIFlask  # 第一行
 from flask import request, escape
 ​
 app = APIFlask(__name__)  # 第二行
 ​
 @app.route('/')
 def hello():
     name = request.args.get('name', 'Human')
     return f'Hello, {escape(name)}'

欢迎提出改进建议，报告 bug 或是分享其他任何相关的想法。你也可以在 GitHub 上创建 Issue，或是提交 PR 来改进它。谢谢！