先说结论：网上那些「Django 27%、Flask 23%、FastAPI 19%」的占比，查不到出处。真正能引用的那份调查，数字是另一套。而「AI 全栈三天上线」这句话只对了一半——快的部分快得离谱，慢的部分一点没变。下面把数据、国内的真实情况、和一笔工时账，逐个摆出来。

一、先泼一盆冷水：你搜到的占比，大多是编的

为了写这篇，我把中英文的框架占比都翻了一遍。结论有点扫兴：同一个「根据 2025 年最新开发者调查」的说法，至少有三套互相矛盾的数字在流通——27%/23%/19%、38%/29%/21%、35%/34%/38%。

三套数字，都被冠以「2025 年最新调查」。而真正由 Python 软件基金会和 JetBrains 联合发布的那份，覆盖三万名以上开发者，2025 年 9 月公布，全球只有一套数字。

这不是小事。在各种选型讨论里，最容易被滥用的就是「占比」，因为它看起来客观。一个没有出处的百分数，被十篇文章转引之后，就变成了一个「事实」。

所以下面我只用能追溯来源的数，而且每一个都标清楚它到底在测什么。

二、全球口径：唯一值得引用的那份调查

PSF × JetBrains，2025 年 9 月发布，样本三万名以上 Python 开发者：

 1. FastAPI 使用率 38%，一年之内从 29% 涨上来

 2. Django 35%

 3. Flask 34%

 4. 46% 的 Python 开发者用 Python 做 Web 开发

 5. 50% 的受访者专业编码经验不到两年

 6. 83% 仍在运行旧版本 Python

 7. 69% 计划尝试 AI 编码智能体

先说最容易被标题党带偏的那条：三强其实已经拉平到统计误差以内。所谓「FastAPI 登顶」，正确的理解是「FastAPI 追上来了」，而不是「Django 输了」。

真正值得看的是第四和第五个数字。做 Web 开发的人占 46%，但一半受访者经验不到两年——这一条解释了为什么「教程里的框架分布」和「生产环境的框架分布」完全是两回事。新手教程密集的地方声量大，可声量不等于存量系统。

Stack Overflow 2025 的全语言调查是同一趋势：FastAPI 14.8%，Flask 14.4%。绝对值低得多，因为那个样本里大部分人并不用 Python，但交叉的方向是一致的。

还有一份容易被忽略的交叉证据。JetBrains 的 Django 开发者调查 2025 问了 Django 开发者一个问题：除了 Django，你还在用什么 Web 框架？答案里 FastAPI 占 28%，Flask 占 23%。

这说明什么？它们不是替代关系。同一个团队里，Django 管业务和后台、FastAPI 管对外接口和 AI 服务，是常态而不是例外。把这三者当成一道三选一的单选题，这个提问方式本身就是错的。

三、下载量：一个更容易被读错的指标

2026 年 8 月的 PyPI 月下载量，大致是这样的：

 1. Starlette 约 6.1 亿～6.8 亿

 2. aiohttp 约 6.3 亿～6.5 亿

 3. FastAPI 约 5.6 亿～5.9 亿

 4. Flask 约 2.0 亿

 5. Tornado 约 1.2 亿

 6. Django 约 5300 万～5500 万

 7. Django Ninja 约 310 万，Litestar 约 200 万

看到 Django 排在 Flask 后面、比 FastAPI 少一个数量级，很多人的第一反应是「Django 不行了」。这个结论是错的，原因有三个。

第一，依赖链放大。每一个 FastAPI 安装都会顺带拉 Starlette，所以 Starlette 的下载量必然大于等于 FastAPI，这是依赖结构决定的，不是用户选择。aiohttp 更冤，它大部分时候是当 HTTP 客户端用的，压根不是「Web 框架使用量」。

第二，安装次数不等于部署次数。Django 一个站点装一次，之后几个月不再装；FastAPI 每次 CI、每个容器构建都要装一遍。做测试的同学对这个最有感觉——你的流水线跑一次，PyPI 就多几十个下载。

第三，AI 生态在替 FastAPI 刷量。vLLM 的 OpenAI 兼容服务、LangServe、各类推理服务把 FastAPI 当默认 HTTP 层，装它们就顺带装了 FastAPI。

所以下载量这个指标，正确的读法是「这个包有多难避开」，而不是「多少人选了它」。

那什么在动？趋势。FastAPI 月下载同比约 +22%，Django 约 +3%，Flask 约 -1.4%——三个里面唯一在下跌的就是 Flask。方向比绝对值可靠得多，这一条后面还会用到。

四、国内：没有调查，只有三个侧面

必须先说清楚一件事：国内没有一份覆盖三万人的、公开方法论的 Python 框架调查。任何「国内 Django 占比 XX%」的说法，要么是估算，要么是编的——包括我下面要引的这份。

有一份流传较广的国内技术栈调研给出：Spring / Spring Boot 40%、Django 与 Flask 合计 20%、Express / Koa 15%、Gin / Echo 12%。它没有公开样本和方法，只能当量级参考。但它传递的信息是有效的：在国内后端的整体盘子里，Python 大约是 Java 的一半。这个量级判断，和招聘 JD、和实际项目里的观感是一致的。

在承认数据不足的前提下，国内可以用三个侧面去逼近真实格局。

侧面一，看招聘 JD 的措辞。Django 和 Flask 的出现频率仍然最高，集中在传统企业、外包、内部系统类岗位。FastAPI 岗位近两年增速最快，但绝大多数写的是「熟悉 FastAPI / Django / Flask 之一即可」，而不是「必须 FastAPI」。这个措辞本身很说明问题：企业要的是能交付后端的人，不是某个框架的专家。框架在 JD 里是筛选词，不是岗位定义。

侧面二，看需求的性质变了没有。国内 Python 后端的存量需求，集中在内部系统、数据平台、中后台、自动化工具。这类需求的核心特征是：表多、权限复杂、需要一个人能点的界面。Django 的 admin 在这里是碾压性优势——十几张表的增删改查，admin 一开就有了，这部分工作量是白送的。我自己维护的一个元数据管理平台就是十三个模型，后台界面几乎没有单独写过一行前端。

而增量需求偏 AI：模型服务、Agent 后端、RAG 接口。这类需求没有业务表、不需要后台、要的是流式和并发，FastAPI 是默认答案。

这就是我判断国内格局是「双峰」而不是「三足」的原因：Django 吃存量业务系统，FastAPI 吃增量 AI 接口，Flask 卡在中间被两头挤。前面那条「唯一在跌的下载曲线」，和这个判断是自洽的。

侧面三，看 AI 生态的默认技术栈。vLLM 的 OpenAI 兼容服务、LangServe、Xinference 这类推理与编排服务，HTTP 层基本就是 FastAPI。国内做 AI 应用的团队，项目模板往往是照着这些抄的。这一层「事实标准」，比任何调查报告都更能决定新项目的默认选择。

所以如果非要一个方向性的答案：存量看 Django，增量看 FastAPI，Flask 的份额在被稀释。至于具体比例，没有可信数据，我不会编一个给你。

五、选型别看占比，看你的成本结构

三个问题，问完基本就能定。

 1. 你要不要一个后台？要，就选 Django。这是唯一一个自带可用管理后台的选项，省下的不是几天，是几个月的界面工作量。不要，往下问。

 2. 你的瓶颈是 IO 还是 CPU？IO——等模型、等数据库、等第三方接口——选 FastAPI，ASGI 是真的能扛并发。CPU 密集的话，换框架没用，去拆任务队列。

 3. 团队里有没有人能兜架构？没有，就别选 Flask。Flask 的自由度是留给「能定架构的人」的，缺这个人，项目做到第三个月必乱。

补一句关于性能的口径问题。网上那些 QPS 对比——FastAPI 8500、Flask 2800、Django 1200——基本都是 hello world 跑出来的。真实业务里，瓶颈在 SQL 和序列化上的比例，远高于在框架的路由分发上。拿 hello world 的倍数做架构决策，是最常见的一类误判。

六、AI 全栈到底有多快

先把「快」拆开。写第一版快，和上线快，是两件事。混在一起谈，就会得出「三天上线」这种结论。

证据一，METR 的随机对照实验，2025 年 7 月发布。16 名资深开源维护者，246 个真实任务，全在他们自己最熟悉的仓库上。结果：允许使用 AI 的那组，完成任务反而慢了 19%。

更值得看的是他们的主观感受。事前他们预测 AI 会让自己快 24%，做完之后、在已经经历过变慢的情况下，他们仍然认为 AI 让自己快了 20%。秒表和体感之间，差了将近 40 个百分点。

原因不神秘：AI 给的建议往往「方向对，但不精确」，资深的人得花时间读、判断、改。在你自己写过三年的代码里，这个开销大于收益。

证据二，METR 2026 年 2 月的更新。换成 2025 年底的工具重做，同一批老开发者的成绩变成快 18%（置信区间 -38% 到 +9%），新招募的 47 人是快 4%。METR 自己的措辞很克制，说这是「非常弱的证据」——因为 30% 到 50% 的开发者拒绝提交「不许用 AI」的任务，样本被筛过一轮，真实提升很可能被低估。

但方向是清楚的。一年之内，点估计从「慢 19%」翻到了「快 18%」。

证据三，METR 2026 年 5 月对 349 名技术工作者的问卷。自报价值提升中位数 1.4 到 2 倍，自报速度提升中位数 3 倍。回顾 2025 年 3 月是 1.3 倍，评估 2026 年 3 月是 2 倍，预测 2027 年 3 月是 2.5 倍。

有个细节很有意思：所有受访子群里，METR 自己员工的估值最低。大概是他们太清楚「感知」和「实测」能差多少。

我的解读是：红利并不均匀，它高度集中在特定环节。按任务类型粗分，大致是这么个分布（汇总口径，非单一实验）：

 1. 样板代码与 CRUD：+70% 到 +90%

 2. 单元测试：+70% 左右

 3. 文档：+65% 左右

 4. 系统设计：+10%

 5. 陌生代码库里的修改：-19%

Python 全栈恰好落在红利最厚的那一档。原因很具体：

 1. FastAPI 加 Pydantic 把接口契约变成了类型声明。类型声明是能被 AI 直接生成的，而且生成完能校验、能出文档、能给前端用——一次投入、四处复用。

 2. 前端可以不用写。Streamlit 或 Gradio 几十行出一个能演示的界面；正式一点，Next.js 模板加 shadcn，AI 生成组件基本可用。

 3. 数据层一套模型两用。SQLModel 或 SQLAlchemy 的模型既能建表，又能当 API schema。

 4. 部署链路短。uv 加 Docker 加一个托管平台，从 git push 到有公网链接是分钟级。

但真实的工时账是这样的（我的经验口径，不是调查数据）：

 1. RAG 问答 demo：上传文档 + 向量检索 + 流式回答，半天到一天

 2. 加上登录、会话历史、限流、基础审计：3 到 5 天

 3. 做成能给客户用的——多租户、配额、监控、评测集、灰度：3 到 6 周

从「能跑」到「能交付」，中间那 90% 的距离，AI 帮的忙很有限。因为那段距离里堆的是权限、并发、可观测性、数据一致性——这四样没有一项是 AI 能替你决策的。

所以「AI 全栈有多快」的诚实答案是：原型阶段 5 到 10 倍，产品阶段 1.2 到 1.5 倍。宣传里的「三天上线」，绝大多数停在了原型阶段。

七、三条能直接用的建议

 1. 做内部平台、数据工具、测试中台，从 Django 起步。admin 白送的界面工作量，是在这个方向上最大的杠杆。省下的时间别去堆功能，花在数据模型设计上——那才是这类系统真正的难点。

 2. 做 AI 能力对外提供服务，从 FastAPI 起步。OpenAPI 自动生成，前端省一半，前端同学会感谢你。

 3. 两者不必二选一。同一个 PostgreSQL，Django 管业务表和后台，FastAPI 挂 /v1 做推理接口，一个 Django 项目加一个独立 FastAPI 服务就能拼起来。这不优雅，但极其有效，也是现在很多团队的真实架构。

最后回到那个最初的问题。框架占比是别人的选择，成本结构才是你的答案。

AI 让你写得更快，但没有让你想得更快。省下来的时间如果不花在设计、验收和边界条件上，它会以返工的形式，一分不少地还回来。

更多相关技术内容咨询欢迎前往并持续关注好学星城论坛了解详情。

想高效系统的学习Python编程语言，推荐大家关注一个微信公众号：Python编程学习圈。每天分享行业资讯、技术干货供大家阅读，关注即可免费领取整套Python入门到进阶的学习资料以及教程，感兴趣的小伙伴赶紧行动起来吧。