刷到小红书那个帖子的时候，评论区已经吵了 169 层。
楼主的问题就一句：为什么软件公司很少用 Python 开发 web？小红书这条帖子拿到 101 赞、67 收藏，评论区两派吵得很整齐：一派说"Python 慢、GIL 锁死并发、大厂根本不用"，另一派说"先跑起来再说，性能不够再优化"。同样的问题搬到知乎，也有将近 5 万阅读。
如果你正在学 Python Web，或者正用它干活，这个问题大概率也在你心里转悠过：我投入的这门手艺，是不是选错了？
我把知乎、小红书、B站最近几个月的讨论翻了一遍，又对照了 Python 官方的版本节奏。结论先放这儿：这个争论里有一半是事实，另一半是停留在五年前的认知。
"Python 慢"的吐槽，拆开看基本是三种错觉
先说对 Python 不利的那部分证据，不回避。
国内互联网大厂的后端主力确实是 Java/Go，Python 在大型业务系统里的存在感整体偏弱，这是事实。原因也不神秘：Java 生态在国内企业级市场积累了十几年，招人、中间件、运维体系都是现成的；Python 早年的 GIL 也确实让它在多线程 CPU 密集场景吃亏。
但也别急着下"没人用"的结论——Meta 旗下的 Instagram，到今天仍然跑着全球最大的 Django 集群。知乎"大厂不用 Python 做 Web"这个说法，至少在海外不成立。
但"Python 不适合做 Web"这个结论，推导过程有个大漏洞——它把"Web 服务慢"直接算在了解释器头上。
知乎上有个 113 赞、163 收藏的回答，把"感觉 Python 越来越慢"拆成了三种情况，我觉得拆得很准：
第一种，依赖膨胀。 五年前一个 Flask 项目启动 0.3 秒，现在同样的项目装了一堆中间件、ORM、监控 SDK，启动要 3 秒。不是 Python 慢了，是你的 requirements.txt 胖了。
第二种，数据量涨了。 处理 1 万行 CSV 的时候 for 循环够用，处理 100 万行同样的代码就卡住。代码没变，数据变了。
第三种最典型：I/O 等待被算成了 Python 慢。 一个请求里数据库查询 200ms、外部 API 调用 500ms、文件读写 100ms，加起来 800ms，Python 自己的计算可能就花了 20ms。但你打日志看到的只是"这个接口跑了 820ms"。
Web 后端恰好是第三种的重灾区。你接口慢，大概率慢在 SQL、慢在下游服务、慢在没加缓存，而不是慢在 Python 解释器。那位答主举了个例子：他用 py-spy 给一个 Django 项目做剖析，发现 40% 的时间耗在 ORM 的 `getattr` 里——一个 `select_related` 就解决了，典型的 N+1 查询。
所以"Python 做 Web 慢"这个判断，更准确的说法是：未经剖析的 Python Web 项目，慢因几乎都不在语言本身。
但解释器这次是真在变快：3.13 → 3.14 → 3.15 的时间线
再说对 Python 有利的那部分，也是很多人没跟上的部分。
Python 最近三个版本，主线任务就一个字：快。
3.13（2024 年 10 月）：引入实验性 JIT 编译器，同期开始推 Free-threading（去 GIL）实验构建；
3.14（2025 年 10 月 7 日发布，代号"πthon"）：JIT 和去 GIL 继续以实验特性迭代；
3.15：预计今年 10 月发布，社区关注度明显起来了——5 月份 Reddit 上一篇 3.15 更新清单的帖子就拿了 160 票。
已经能查到的社区实测数据，给大家划一下重点，注意口径：
知乎有篇讲 3.15 JIT 的文章提到，在部分基准测试里 JIT 构建比标准解释器快 5%–12%，x86_64 Linux 上快 5%–6%。知乎这个数字不惊艳，但背景值得说：CPython 的 JIT 一度险些夭折，核心贡献者流失后是社区接管推进的，这个提升是"回魂"式的一步。
另有答主转述 Reddit 的 changelog 总结，称 3.15 可能把 JIT 转默认、重写 asyncio 事件循环调度、把对象头从 24 字节压到 16 字节（内存降 15%–20%）。这些说法目前只有社区转述这一个来源，具体以 10 月官方发布说明为准，但方向上是多方讨论都认可的：3.15 就是冲着性能去的。
大厂也没闲着。今年 2 月 Meta 开源了 CinderX（基于自家内部 Cinder 发行版的编译优化方案）。其仓库基准测试显示，CinderX JIT 加 Static Python 的组合跑 Richards 测试，速度达到了原生 CPython 3.14 的 18 倍。知乎数字取决于具体场景和基准，别当承诺看，但 Meta 把生产线上跑 Python 的优化拿出来开源这件事本身，说明"Python 扛不动生产"至少不是 Meta 的世界观。
那为什么 B 站全是 FastAPI 课程？需求端其实变了
说完性能，看个更实在的信号：大家实际在学什么、用什么。
我扫了一圈 B站和知乎最近的 Python Web 内容，有个很明显的结构性变化——FastAPI 已经是新项目的默认选项。B站"挑战十小时学会 FastAPI"这类课程播放量轻松上万、收藏 474。哔哩哔哩知乎上"FastAPI 筑基"连载专栏在日更，从依赖注入一路写到 SQLAlchemy 实战；连本地部署大模型的文章，标准姿势都是"MLX 跑模型 + 独立 FastAPI 服务提供接口"。
为什么是 FastAPI？因为它踩中了这两年的主线需求：写 API、包模型、上异步。 AI 应用的爆发让"给模型套一层 HTTP 服务"成了高频场景，FastAPI 的类型注解校验、自动 OpenAPI 文档、async 原生支持，正好全打在需求上。
而 Django 这边，基本盘依然扎实。知乎"学 Django 学得很迷茫怎么办"这种问题有上百万阅读，说明学习者规模一点没缩。知乎它也没有停在原地：从 django-debug-toolbar 官方示例的截图看，版本已经迭代到 Django 6.0.6；而 Django 5.2 作为 LTS 版本，官方安全更新能到 2028 年 4 月。走管理后台、内容型系统、全栈路线的团队，它仍然是最稳的选择。
所以"大厂很少用 Python 做 Web"这句话，需要加两个时间限定：它说的是传统企业级业务系统的历史格局，而 AI 服务和中小团队快速开发这两个新增场景里，Python Web 的份额其实在涨。
三个框架怎么选：对号入座
别再问"哪个框架最好"，按场景分：
选 Django：需要现成的 admin 后台、用户认证、ORM、内容管理；团队有人写过 Django；项目偏"信息系统"而非纯 API。它的哲学是自带电池，代价是框架约定多、定制深的地方要跟它斗智斗勇。
选 Flask：小工具、内部服务、想一步步理解 Web 框架原理的人。它轻到只有一个路由和请求响应，其余全靠自己拼装——这既是自由，也是工作量。
选 FastAPI：对外 API、AI/模型服务、需要异步高并发、团队习惯类型注解。它是当前新项目的最大公约数，也是社区教程供给最猛的。
另外两个值得放进观察列表的：纯 Python 写 Web UI 的方向（比如 Google 开源的 Mesop，不想碰前端三件套的数据/AI 方向同学可以关注）；以及 Litestar 这类 FastAPI 替代方案在小圈子里的讨论。
项目真慢的话，先做这三件事再谈换语言
最后给已经在干活的同学一份"先别慌"清单，都是社区验证过的动作：
跑一次 py-spy。 `py-spy top – python your_script.py`，不改代码不加埋点，先看 80% 的时间到底花在哪。多数人会第一次看清自己的项目瓶颈。
查 N+1 查询。 Django 开 django-debug-toolbar，SQLAlchemy 开 `echo=True`。修一个 N+1 的收益，经常比换一个更快的框架还大。
数据场景换引擎。 如果用 pandas，3.0 开始支持 Arrow 后端，`pd.read_csv(file, engine=‘pyarrow’)` 一行改动，常见 2–3 倍提升。
做完这三步还慢，再谈架构、谈缓存、谈把热点模块换语言——那时候你也知道该换的是哪 5% 了。
值得持续盯的信号
今年 10 月 Python 3.15 正式发布：重点看 JIT 的状态、asyncio 的改动和内存数据，发布说明出来之前，社区流传的"翻倍"数字都先按传言处理；
FastAPI 的 1.0 动向：长期停在 0.1xx 版本号，社区一直有发 1.0 的讨论，如果落地会是生态的一个节点；
去 GIL（Free-threading）构建的生态兼容进度：这是 Python 并发叙事的根，第三方库的支持面值得每半年看一眼。
回到开头那个 169 条评论的帖子。"软件公司很少用 Python 做 Web"是历史事实，但拿它当 2026 年的择业劝退理由，属于用旧地图找新大陆。Web 后端的瓶颈大多在 I/O 和 SQL，解释器在肉眼可见地变快，而 AI 这一波又把 FastAPI 这种 Python 框架推到了新场景的正中央。
与其在评论区吵"Python 行不行"，不如先给手头的项目跑一次 profiler——很多争论，剖析报告出来三秒就结束了。
