FastAPI还是Flask：异步快7.8倍，也可能毫无优势

在Uvik的单核I/O微基准中，50个并发客户端请求带有50毫秒模拟等待的接口，FastAPI配Uvicorn的单工作进程吞吐为每秒149.7次请求，Flask配Gunicorn的单同步工作进程为19.2次，约相差7.8倍；Flask使用4个同步工作进程时达到74.8次。这个数字属于特定服务组合和负载，不能当作两个框架在生产环境中的固定速度差。

选择FastAPI还是Flask，先看请求时间花在哪里：高并发且主要等待可异步调用的下游服务，新建API更适合评估FastAPI；计算占主导、并发较低，或现有Flask应用深度依赖扩展时，异步吞吐优势可能抵不过改造成本。性能之外，请求校验、接口文档和现有部署方式也会改变总成本。

模拟等待为何拉开吞吐

实验中的两个接口都在等待后返回简单JSON。FastAPI路由用async def和await asyncio.sleep在等待期间让出执行权；Flask同步路由用普通def和time.sleep，占住当前同步工作进程。并发请求到来时，前一种配置能把多次等待交叠起来，后一种配置则需要空闲进程接手。这个对照解释了吞吐差距，但模拟休眠无法代表实际查询、连接池竞争或下游限流。

要复现这一对照，两个接口应使用相同的CPU配额、响应内容、等待时间、客户端并发量和测试时长，并写清服务器与工作进程配置。还应同时记录吞吐、延迟分布和失败请求：单位时间内完成更多请求，并不保证每个请求都更快。短时微基准适合观察并发机制，容量规划仍须使用具有代表性的业务接口。

Flask异步视图的收益在哪里

Flask官方异步说明指出，异步视图处理请求时仍占用一个WSGI工作进程，因此把路由改成async def，不会直接增加该部署同时处理的请求数。它能让同一视图内彼此独立的查询或HTTP调用并发等待，从而缩短这次请求的总等待时间；对CPU密集任务，异步也没有天然加速作用。

视图内部的等待可以重叠，不等于其他请求能进入已占用的同步工作进程。现有应用还要检查扩展兼容性：早于Flask异步支持的装饰器可能不会等待异步视图，扩展提供的同步函数也可能阻塞。认证、缓存或请求处理若依赖这些扩展，修改路由声明只是改造的一部分。

工作进程为何改变结果

Flask的Gunicorn部署说明给出了用-w设置进程数的方法，并介绍了不同工作模式。增加同步进程后，等待中的请求可由其他进程处理；换用线程或其他工作模式，比较对象也随之改变。因此，一次性能结论至少应说明服务器、进程数、工作模式、资源配额和并发量。

单进程对单进程的比较回答的是：在这种配置下，等待能否有效重叠。迁移决策还应比较资源预算相近的可用部署方案。更多进程可能提高同步服务的处理量，同时增加内存和连接占用；若现有Flask部署已达到吞吐与延迟目标，更换框架的收益就需要另找依据。

阻塞库与CPU任务会怎样改变选择

FastAPI官方并发指南建议：调用支持await的库时使用async def路由；调用不支持await的数据库、网络或文件库时，可使用普通def路由，由框架在线程池中运行。若在async def中直接执行阻塞调用，事件循环无法在那段等待期间处理其他协程。路由写了async，整条调用链却仍同步，预期的并发收益便可能落空。

计算密集任务消耗CPU时间，交叠I/O等待不会缩短计算本身。若长时间计算占住处理请求的执行资源，两种框架都需要考虑进程隔离或任务队列。低并发服务则缺少足够多的等待可供重叠，序列化、校验和业务逻辑的耗时可能更值得关注。判断瓶颈时，应分清请求时间分别花在计算、数据库、网络调用与排队的哪一段。

校验、文档和迁移成本

FastAPI请求体文档展示了Pydantic模型如何解析和校验JSON请求，并把模型的JSON Schema纳入自动生成的OpenAPI及交互式文档。对字段经常变化、需要与调用方协商接口契约的新API，同一份模型连接校验与文档，能减少分别维护定义的工作。团队仍须决定字段约束、错误响应和模型变更规则。

Flask允许应用自行组合校验、认证和文档扩展。新项目可能需要为这些组件花时间选型与集成；成熟应用则可能已把它们接入测试和部署流程。迁往FastAPI时，原有数据定义可能需要改写为Pydantic模型，Flask专用装饰器、请求上下文和中间件需要逐处检查，WSGI部署也要调整为适合ASGI应用的方式。回归测试、错误处理和监控调整同样属于迁移成本。

四种场景如何取舍

• 高并发I/O：新建API主要等待数据库或第三方接口，所用客户端支持非阻塞调用时，优先评估FastAPI；容量仍受连接池和下游限额约束。
• CPU密集：先确定计算如何隔离及并行执行。仅把处理函数改成异步，不会缩短计算过程。
• 低并发：可重叠的等待较少，框架选择可以更多取决于接口契约、文档需求和团队熟悉的部署方式。
• 旧扩展较多：若Flask服务已满足性能目标，保留现有组件通常能减少改造；若少数接口确有等待瓶颈，再评估局部迁移。

评估迁移时，选一个能代表实际负载的接口，比只测模拟休眠的路由更有用。让候选部署使用相近的资源预算，并纳入实际驱动、下游调用、校验与响应生成，再比较吞吐、延迟和错误率。这样才能判断框架变化是否解决了当前瓶颈，以及收益能否覆盖迁移工作。

相关阅读：

• Cloudflare Workers还是Vercel：冷启动更快，也可能更难迁移
• Airtable还是Notion：20美元同价，付费成员算法会改变总账
• HubSpot还是Zoho CRM？免费起步后，席位数会先改变账单