在 2025 年 12 月到 2026 年 8 月这八个月里，Django 发布了两个功能版本，并重写了整套发布节奏。
而这一切发生在一个自 2023 年以来口碑几乎没变的框架身上：那个开箱即用、开发效率高、有自己主张、只支持同步、并且正在被 FastAPI 蚕食的 Python 框架。「只支持同步」这个标签已经过时，人气的故事也比头条数字复杂得多。
所以，关于 Django 在 6.1 版本上是否还值得用，我的结论是这样：一个带评分的判断、它适合的项目形态，以及现在更适合交给 FastAPI 的形态。
简短版本
是的，但有条件。当后台管理、认证、表单和 ORM 构成大部分工作时，Django 6.1 依然是最稳的默认选择，而异步方面的差距也已缩小到「只支持同步」不再是排除它的理由。它不适合一个没有后台界面的高并发单一 API。 4 分（满分 5 分）。
- 你买的就是这一整套。 ORM、迁移、带权限的会话认证、表单层，以及自动生成的后台管理，是一起到位并且已经彼此打通的，而不是五个库外加它们之间的接缝。
- 后台任务是薄弱环节。 Django 6.0 的 Tasks 框架给了你一个装饰器和一个入队调用，却没有 worker，所以选 Celery 还是同类方案，依然要你自己决定。
- 异步支持好了很多，也明显还没做完。 Django 支持异步视图和异步 ORM 调用，但事务在异步模式下不可用。在 WSGI 下，异步视图仍能在单个请求内并发执行异步 I/O，但你得不到完全异步请求栈的好处；长时间运行的请求和高连接并发需要 ASGI。
- 规划 2027 年之后的事变容易了。 从 2028 年 1 月起，Django 每年发布一个功能版本，每个版本都带三年支持，而「LTS」这个标签也随之取消，因为现在每个版本都享有同样的承诺。
- 适合后台管理和 CRUD 占大头的产品，也适合小团队。 不适合没有后台管理、也没有表单的单一高吞吐或流式 API，那种场景下 FastAPI 是更自然的选择。
这篇评测是怎么写成的： 这是一篇对 Django 6.1 的评估，依据是项目自己的发布说明和文档、Django Software Foundation 在 2026 年 8 月发布的治理公告、2024 年 JetBrains/PSF 与 2025 年 Django 开发者调查，以及公开写下自身生产经验的具名从业者。我没有为这篇文章做长达数周的生产试用，这里也没有任何基准测试：没有做过压力测试。Django 是免费的，采用 BSD 许可，我与该项目没有任何关系。
自 2025 年以来 Django 究竟变了什么？
Django 6.0 于 2025 年 12 月 3 日发布，带来了官方自研的 Tasks 框架以及其他核心新增内容。 异步 ORM 接口 出现得更早：Django 4.1 早在 2022 年就引入了异步 QuerySet 操作。Django 6.1 于 2026 年 8 月 5 日成为当前稳定版。随后在 2026 年 8 月 10 日，该项目宣布 每年一个功能版本 自 2028 年 1 月起施行，每个版本三年支持，并取消 LTS 标签。
6.1 的发布说明 确认 6.1 支持 Python 3.12、3.13 和 3.14，主线支持在 2027 年 4 月结束，延长支持在 2027 年 12 月结束。
版本号也随之改变。它们会带上年份，于是有了 Django 2028，接着是 Django 2029（至少「你们跑的是哪个版本」这个问题好回答了）。这三年拆成一年常规缺陷修复，加上两年安全与数据丢失修复，而这正是过去 LTS 的含义，所以这个标签也就没必要了。
这给今天启动的项目留下了一个尴尬的窗口。Django 5.2 是当前的 LTS，支持到 2028 年 4 月。Django 6.1 是当前稳定版，但它的延长支持在 2027 年 12 月结束，比 Django 5.2 的支持窗口在 2028 年 4 月到期早了大约四个月。
所以：追求最长支持窗口，就从 5.2 起步；想要 Tasks 框架和 6.x 的最新特性，就从 6.1 起步，并接受更早的一次升级。两条路都没错，而这个尴尬的选择会在 2027 年 4 月 Django 6.2 LTS 到来时消失。
我把这次节奏调整看作好兆头。走下坡路的项目只会悄悄拉长自己的支持承诺，而不会带着明确日期的计划公开重构它。这个项目只是把它本来就在兑现的承诺理顺了。
Django 至今仍胜过一切的地方
开一个 Django 6.1 项目，你在写下第一个功能之前就已经有了：可用的会话认证外加权限系统、能校验也能渲染的表单层、与模型绑定的迁移系统、ORM，以及自动生成的后台管理。这就是它全部的卖点，也是 Django 中一直不需要改动的那部分。
价值不在于这些部件存在，而在于它们是彼此对着设计出来的。同一套模型权限直接供给后台管理，改一次模型就同时生成迁移并更新后台表单。
用一堆独立的库拼出同等的覆盖面，最终是能做到的。同时你也会在每一处接缝上得到一块永久的维护面，而缺陷正是住在接缝里。
后台管理是给内部员工用的工具。 后台管理的参考文档 写明它的推荐用途仅限于组织内部的管理工具，并不适合把你的整个前端围绕它来搭建。模型权限决定员工进去之后能做什么，而想进去本身则需要 is_staff。把这当作一条约束，而且是条好约束：你白得一个够用的内部后台，却得不到面向客户的界面，于是没人会被诱惑着把它端上去。
安全默认值是同一论点的另一半。CSRF 防护、通过 ORM 做 SQL 参数化、模板中的 XSS 转义、点击劫持防护，这些都是默认开启的，而不是资深开发者得记着在评审里提出来的事项。一个小团队直接继承了那些读过十年安全报告的人所做的选择。
再说年头。它常被读成包袱，我读到的却是生态的论据。Django REST Framework 就在那儿，而且它「无聊」得恰如你希望基础设施应有的那种无聊。
针对你第四个月才会撞上的问题，那些成熟的包也一样：过滤、限流、存储后端、多租户模式、审计日志。而当某个问题冷僻到没有任何包覆盖时，通常能找到一条十五年前的邮件列表讨论。论广度，我不认为 Python 里还有别的东西能接近，而这条轴线正是人们最初选择 Django 的原因。
Django 的短板在哪里
Django 至今仍缺少覆盖整个框架的官方类型标注，保守的节奏留下了「开箱即用」不会提醒你的空白，而 6.0 的 Tasks 框架没有 worker。这就是 6.1 上的三处不足。类型上的空白是每天让你难受的那一处；Tasks 则是会改动你架构图的那一处。
类型这块的大部分，你仍然要靠第三方工具自己拼起来。 django-stubs 提供了类型存根，外加一个针对 Django 动态行为的定制 mypy 插件。它当前的文档写明完整支持 mypy，并对 pyright、pyrefly 和 ty 提供基础支持。这比过去好，但它终究是一层独立的兼容层，而不是 Django 自身完备的官方类型标注。
如果你是从一个围绕类型注解构建的框架转过来的，这在日常编辑器体验上是一次可感的倒退。
保守的节奏既是美德，也是代价。Django 加东西谨慎而迟缓，这正是你 2019 年学的那套框架今天还读得懂的原因。这也是「电池」到此为止的原因：核心里没有 WebSocket 层，没有调度器，对异步任务编排也不表态。越过其中任何一条线，你就又要自己动手拼装了。
Django 6 还需要 Celery 吗？
不一定非得是 Celery。Django 6.0 的 Tasks 框架统一了任务如何定义和入队，但它本身并不执行排队的工作。到了生产环境，你仍然需要一个后端或 worker 进程去执行任务；Celery 只是选项之一，并非框架的硬性要求。 Django 6.0 的发布说明 把这条边界说得很直白：Django 负责任务的创建与入队，但不提供 worker 机制，执行必须由外部基础设施来管理，比如一个独立的进程或服务。
你拿到的是接口：
from django.core.mail import send_mail
from django.tasks import task
@task
def email_users(emails, subject, message):
return send_mail(subject, message, None, emails)email_users.enqueue(...) 会把任务送到已配置的后端。而 6.0 自带的那两个后端是给开发和测试用的（也就是说，不是你盼着的那个）。定时、周期执行、重试和持久性，全都不在范围之内。
现役 Django 开发者 Kevin Renskers 把这一点说得最锋利，见 他对 Tasks 的评测:
结果我们拿到的，是一个没有实现的抽象。
就形态而言他说得没错。但那个意图，我会换个说法。在 Steering Council 关于 DEP 14 的投票中，也就是这一功能背后的 Django 改进提案里，Simon Charette 主张它「本应是让 Celery、RQ 这类框架接进来的东西」，而提案作者则把它描述为后台 worker 的接口，而非运行时。所以公允的批评并不是 Tasks 坏了，而是它比「开箱即用」让人期待的要窄得多，它填上的是那个无聊的空白：你的应用代码可以在不导入某个特定队列库的情况下把工作入队。
所以，凡是需要重试、定时任务或失败可见性的 Django 6.1 项目，都要为任务队列留出预算。这跟 6.0 之前是同一笔开销；如果你指望这个版本能把它从架构图上抹掉，那并没有。
如果你已经确定 Django 合适，又不想从零搭建服务器这一层， Cloudzy 的 Django VPS 会给你一个自管理的起点，Django、Gunicorn、Nginx 和 PostgreSQL 都已就位，需要 Redis 或 Celery 时还有 root 权限。这台服务器依然要你自己运维：你省掉的是从空机器开始的搭建，不是运维责任。
Django 的异步支持现在够用了吗？
好到「它只支持同步」不该再拦住你，却还没好到可以在它之上搭建一个完全异步的数据层。在 6.1 上，这两半都成立。哪一半适用于你，取决于你在造什么，以及你用 ASGI 还是 WSGI 来承载它，因为正是这个选择决定了你能否得到完全异步的请求栈，以及对长连接的高效处理。
能力这一面没有争议。凡是会触发 SQL 的 QuerySet 方法，都有一个带前缀 a的异步版本。 async for 可以用在 QuerySet 上，异步数据库 API 里也包含模型方法，比如 asave() ，以及 QuerySet 方法，比如 acreate()。你可以写一个异步视图，直接 await 查询和并发的外发 HTTP 调用，不需要线程池包装。跟当年那句「只支持同步」批评所针对的 Django 相比，这已经是另一个框架了。
决定行为的是部署协议，而不是框架版本，而这恰恰是 Django 自家论坛不得不反复解释的地方。 异步主题指南 写明在 WSGI 服务器下，异步视图运行在各自一次性的事件循环里，所以你可以使用异步特性，但「你不会得到异步栈带来的好处」。
在不动用 Python 线程的情况下服务数百个连接、慢速流式传输、长轮询：这些都需要 ASGI。同样的代码，不同的并发行为，而框架里没有任何东西会告诉你此刻拿到的是哪一种。
这种误解命很长。一位名为 tomcypress 的用户曾开了 一个 Django 论坛帖子 ，问的是为什么连续打到一个异步视图的请求没有全部执行各自的后台工作，论坛常客 KenWhitesell 便把他指向了 WSGI 的事件循环。那次对话发生在 2021 年，到了 6.1 依然一字未改。
而且它还在被外部不断强化。TechVidvan 那篇 Django 优缺点的页面告诉读者，Django「无法同时处理多个请求」，这对 Django 6.1 而言是错的，也正是那种在评估开始之前就把评估终结掉的说法。并发不是框架缺的东西，而是部署方式决定的东西。
真正的硬性障碍是事务，而 Django 自家的异步文档 把话说得很直白：
事务在异步模式下尚不可用。如果你有一段代码需要事务行为，我们建议把那段代码写成单个同步函数，并通过以下方式调用：
sync_to_async().
同一页面把框架中某些关键部分归类为「异步不安全」，并阻止它们在异步上下文中运行，抛出 SynchronousOnlyOperation 。所以一个 Django 6.1 异步应用的形状就是：异步视图加异步读取，凡是写操作需要原子性的地方就留一座同步孤岛。行得通，但这跟一个原生异步的框架不是一回事。我在这条轴上的判断是：明显变好了，没做完，而且对任何不以并发为先的项目来说都是明确的通过。
FastAPI 是否让 Django 成了错误的默认选择？
对某一类特定且还在扩大的项目而言，是的。 2024 年 Python 开发者调查 由 JetBrains 与 Python Software Foundation 于 2024 年 10 月至 11 月间收集，参与者超过三万人。在全体受访者中，FastAPI 为 38%，Django 为 35%，Flask 为 34%。而在选择「Web 开发」作为自己最主要 Python 用途的受访者中，Django 为 61%，FastAPI 为 56%，Flask 为 39%。
把这个问题带进规划会议之前，先看清楚它：这是多选题。受访者被问的是「你用哪些框架」，而不是「你选了哪一个」，一个既维护 Django 单体、又在写 FastAPI 服务的开发者会同时被计入两边。这些不是互斥的市场份额，这里没有谁占了某个市场的 38%。它们呈现的是一个分裂的信号：在全体受访者中 FastAPI 领先 Django，而在主要用 Python 做 Web 开发的受访者中，Django 依然领先 FastAPI。
针对 Django 的那份调查补上了另一个信号，来自已经在用这个框架的人。 2025 年 Django 开发者调查由 Django Software Foundation 与 JetBrains 联合开展，样本为 2024 年 11 月至 2025 年 1 月间收集并经过筛选的 4,655 份回答。结果显示：82% 的人以职业身份写 Django，77% 的人称它是自己用得最多的框架，48% 的人每逢稳定版就升级，一年前这一比例是 40%。受访者为自愿参与，所以它描述的是当前用户群，而不是市场。使用的广度和投入的深度是两种不同的信号，而 Django 的第二个数字比第一个更健康。
FastAPI 胜出的地方，比调查里的差距所暗示的更窄也更锋利。一个由类型驱动的 API 表面，Pydantic 模型就是校验层、生成的 OpenAPI 规范就是契约，这胜过 Django 再加一层序列化器。FastAPI 在请求层是原生异步的，但 它自己的文档写得很明确 ：路径操作两种写法都可以，而用普通 def 声明的处理函数或依赖，会在外部线程池中运行。
而一个没有后台管理、没有表单、没有模板的服务，只是把 Django 的那堆「电池」当死重扛着：你为框架的主张付了钱，却只用上四分之一。如果你造的正是这种东西，那股势头就不是炒作，你应该跟上。
谁该选 Django？
当后台管理、认证、表单和 ORM 构成你接下来大部分工作时，就该拿起 6.1 版的 Django：内部工具、交易市场、后台 SaaS。它同样适合那种需要这些东西第一天就能跑起来的小团队，以及那种现在就得知道自己 2029 年支持窗口长什么样的团队。
框架的主张能覆盖大部分实际工作的产品。 任何带权限矩阵、登录之后一堆 CRUD 的东西。在这里，由框架来做结构性决策是优点而不是代价，因为那些决策本来就是你要自己做的大部分工作。
需要第一天就有产出的小团队。 三个开发、没有平台工程师，一个团队开始写功能，另一个团队开始评估认证库。从那一刻起，这个差距就开始利滚利。
已经在用 Django、正在规划未来三年的团队。 Django 5.2 给你一条支持到 2028 年 4 月的底线，而年度节奏则给出此后可预测的底线。一条读得懂的支持跑道在规划时是值钱的，而这么清楚地被递到手上并不常见。
谁不该选 Django？
别为一个背后没有后台管理的高吞吐或流式 API 选 Django：那种形态的项目，FastAPI 是更干净的默认选择。如果你今年就需要包含事务的异步数据访问，也别选它，因为 6.1 没有。还有，别指望那堆「电池」会替你跑后台任务而选它。
一个没有后台管理、也没有表单的高吞吐或流式单一 API。 在这种形态的项目里，Django 擅长的东西几乎没有一样是承重的，于是你等于为了一个只需要路由器和校验器的服务，去维护一整个框架的结构。
今天就需要完全异步数据访问（含事务）的团队。 Django 6.1 在异步模式下不支持事务。把写操作包进 sync_to_async() 是一种正当的写法，而不是你今年就能摆脱的权宜之计；在无法接受这一点的地方，它是拦路石，而不是小擦伤。
把「开箱即用」理解成连后台任务执行也包含在内的团队。 Tasks 并不附带 worker。如果你的方案假定 6.0 已经把队列从技术栈里去掉了，那么在你押注这个框架之前，得把队列重新加回方案里。
先学哪个 Web 框架是另一个问题，答案也不同；下面的常见问题里有简短版本。
正因为知道 Django 到哪儿为止，起步才是安全的：上面那些出口在你押注之前就看得见，而不是事后才发现。
常见问题
Django 死了吗？
没有。Django 在 2025 年 12 月到 2026 年 8 月之间发布了两个功能版本，还公布了一份延伸到 2030 年代的重构发布计划。FastAPI 增长很快，在 2024 年 Python 开发者调查的全体受访者中以 38% 对 35% 领先 Django；而在主要用 Python 做 Web 开发的受访者中，Django 以 61% 对 56% 领先。一个更年轻的框架增长迅速，和一个更年长的框架死掉，是两种不同的说法。
Django 适合新手吗？
适合，但要注意它是一次要学最多东西的那个。Django 的广度正是它高效的来源，而这意味着新手在做出任何东西之前，就会先撞上 ORM、迁移、模板层和后台管理。反方的说法也值得一读： Bite Code! 的一篇文章 主张新手恰恰应该从 Django 起步，因为它的默认设定挡掉了那些极简框架会放任你独自犯下的架构错误。
Django 比 Flask 快吗？
没有放之四海皆准的答案。这篇评测没有跑任何基准测试，而且在不知道其负载和部署方式的情况下，我也不会相信任何一份基准结果。在很多应用里，数据库查询、N+1 问题和外部 API 调用比框架自身的开销更要紧。如果原始请求吞吐量对你的决策很重要，那就去测你真正打算运行的那套应用和服务器配置。
新项目该从哪个 Django 版本起步？
如果最长的支持窗口最要紧，就从 5.2 起步：它是当前的 LTS，支持到 2028 年 4 月。如果你想要 Tasks 框架和 6.x 的最新特性，就从 6.1 起步，接受主线支持大约到 2027 年 4 月、延长支持到 2027 年 12 月，然后计划在 2027 年 4 月 Django 6.2 LTS 到来时升级过去。Django 6.2 的延长支持预定至 2030 年 4 月。从 2028 年 1 月起，每个年度功能版本都带三年支持。
该先学 Django 还是 FastAPI？
学哪个，取决于你想做什么样的工作。Django 教你一个完整的 Web 应用是怎么拼起来的：数据建模、迁移、认证、表单、模板和后台管理，而结构已经替你定好了。FastAPI 教你带类型的 API 设计和异步 Python，几乎什么都没替你定。抽象地看，两者都算不上对新手友好，而选一个更贴近你目标岗位的，胜过选一个更容易的。
讨论
评论
登录后参与讨论。