数据核对：2026-10-22（GitHub API 实测）

先说结论

• 写 API、要性能和类型 → FastAPI
• 要后台管理、要开箱即用 → Django
• 只要几个接口、不想学框架 → Flask
• 想要 FastAPI 的类型安全但更严格 → Litestar

Python 的 Web 框架格局这几年变化不大：Django 和 Flask 是存量，FastAPI 是增量。新项目里 FastAPI 的出现频率已经超过前两者。

一、三个框架的根本差异

二、实测数据

注意 FastAPI 的版本号还是 0.x。这代表 API 还没承诺稳定，升级时偶尔会有破坏性变更。生产用没问题（大量公司在用），但要读 changelog。

三、逐个说清

FastAPI

核心卖点只有两个，但都很硬：

1. 类型即文档。用 Python 类型标注定义请求和响应，框架自动生成 OpenAPI 文档和交互式调试页（/docs）。接口改了什么，前端立刻能看到。
2. 异步原生。基于 Starlette + Pydantic v2，async def 直接可用，不需要额外配置。

代价： – 不带 ORM。SQLAlchemy、Tortoise、SQLModel 自己选，选错了会很难受 – 不带后台管理，要另找方案 – 异步要考虑清楚。在 async def 里调用同步阻塞库（比如 requests、老的 ORM 驱动）会堵死整个事件循环，性能反而比同步框架差

适合：对外 API、微服务、需要给前端/第三方提供文档的接口层。

Django

二十年积累的全家桶。ORM、后台管理、认证、表单、国际化、缓存、信号，全都有且质量稳定。

最被低估的能力是 admin：定义好模型，后台管理界面自动生成，带搜索、筛选、权限。做一个内部管理系统，Django 能省掉一半工作量。

代价： – 重。一个空项目装完依赖就不小，启动慢 – 异步支持是后来补的，不是原生设计 – 「Django 风格」很强：如果不用它的 ORM 和模板，很多功能就废了

适合：内容型网站、内部管理系统、需要快速上线且需求相对标准的项目。

Flask

微框架，只做路由和请求响应。其余自己拼。

它的价值在「小」：一个 20 行的脚本就能跑起一个接口，不需要理解框架设计。

代价：项目一旦变大，你会自己手搓出一套框架——而且大概率不如现成的。这是 Flask 项目最常见的死法。

适合：脚本型服务、原型、给已有系统加几个接口。

四、按场景选

五、两个容易踩的坑

① 在 FastAPI 里用同步库

# 错误：requests 是阻塞的，会卡住事件循环
@app.get("/proxy")
async def proxy():
    return requests.get("https://api.example.com").json()

1. 正确：用异步客户端
@app.get("/proxy")
async def proxy():
    async with httpx.AsyncClient() as c:
        r = await c.get("https://api.example.com")
    return r.json()

1. 或者：明确定义成同步函数，FastAPI 会放进线程池
@app.get("/proxy")
def proxy():
    return requests.get("https://api.example.com").json()

第三条路最容易被忽略：def 而不是 async def，FastAPI 会自动在线程池里跑。不知道选哪个的时候，写同步的更安全。

② 以为 Django 一定比 FastAPI 慢

Django 也支持 ASGI，配上异步视图和 ORM 的异步接口，差距没有想象中大。真正的瓶颈通常是数据库查询和序列化，不是框架。

六、延伸阅读

• FastAPI 框架入门
• Django 入门
• Flask 入门