91,352 颗星、PyPI 月下载 4,114 万：24 岁的 Django 一天连发三个安全版本冲上 Trending，还悄悄换掉了版本号规则

10 月 9 日早上，GitHub Trending 第一名是 django/django：91,352 颗星、36,540 个 Fork、538 个 open issue、2,273 人 watch，最后一次 push 停在 10 月 8 日 23:59（UTC）。一个 2005 年诞生、官方口号写着”给有截止日期的完美主义者用的 Web 框架”的项目，冲上热榜的原因不是新功能，而是安全——10 月 6 日，Django 一天连发三个安全版本：6.1.2、6.0.9、5.2.18；两天后（10 月 8 日），安全团队又发公告宣布安全漏洞上报方式变更。

这次到底修了什么。 按官方公告，三个版本共处理 4 个安全问题，其中三个已分配 CVE：CVE-2026-77050 是 get_supported_language_variant() 的内存型 DoS——超长语言代码在长度限制之前就被塞进内存缓存，攻击者可以用大量畸形语言码把进程内存吃光（严重度 low）；CVE-2026-84429 更值得关注，parse_header_parameters() 在解析带大量分隔符的引号参数时是二次复杂度，Accept、Content-Type 这类未认证请求头就能触发，经 HttpRequest.accepts() 的内容协商路径直达（moderate）；CVE-2026-87890 则是空间查询（spatial lookup）接受裸 bytes 的栅格值，攻击者可塞进引用外部数据源的 VRT 文档，让 Django 进程以自身用户身份发起网络请求，属于请求伪造范畴。Rapid7 的漏洞库也已收录：CVE-2026-77050 条目。此外公告明确提到”修复了上一次发布中一处不充分的安全缓解”——这说明 8 月 4 日的 6.0.8 补得不够干净，属于二次加固。

一个容易被星数掩盖的事实：Django 的”发布现场”根本不在 GitHub。 用 GitHub API 查 django/django，Releases 数量是 0，tags 列表里只有 stable/5.1.x 这类维护分支标记；真正的版本信息挂在官网 weblog 和 PyPI 上。而 PyPI 的数字才是它的真实体量：pypistats 显示最近一天 1,774,989 次下载、最近一周 10,333,535 次、最近一月 41,143,691 次——月下载 4,114 万，是绝大多数”新锐框架”一辈子都够不着的量级。GitHub 上 91,352 颗星更像是开发主线的镜像，仓库 README 也写得很直白：文档在 docs/ 目录，提问去 Django Forum 和 Discord。

版本节奏和一次安静的”改朝换代”。 最新功能版是 6.1（2026 年 8 月 5 日发布），亮点是模型字段 fetch modes（按需取值）、ForeignKey.on_delete 支持数据库级删除、字典式邮件配置；上一版 6.0（2025 年 12 月 3 日）加入了模板 partials（{% partialdef %}），Adam Johnson 的解读值得配套读。真正的大新闻藏在下载页的支持列表里：从 Django 2028 开始，版本号改为 YYYY 格式、每年 1 月发一版，且每个功能版都享受完整三年支持（此前只有指定 LTS 才有三年）。6.2 会是旧规则下的最后一版（2027 年 4 月，LTS，支持到 2030 年 4 月）。当前支持状态：6.1 主线支持到 2027 年 4 月，6.0 已结束主线支持、安全修复到 2027 年 4 月，5.2 LTS 安全修复到 2028 年 4 月。

社区温度。 2025 年 7 月 Django 过完 20 岁生日，Hacker News 讨论串下最高赞的故事线是”生产应用从 Django 1.4 + Python 2.6 一路升到 Django 5 + Python 3.13，没花过一分钱支持费”——这种跨十年的平滑升级路径，才是它真正的护城河。年度 Django Developers Survey 2025 结果已于去年 10 月底公布，2026 年版问卷正在进行（DjangoChat 有专门一期解读）。中文教程也跟得上：官方 6.1 中文版教程要求 Python 3.12 及以上。

项目边界，说清楚。 Django 是全家桶，不是微框架：开箱自带 admin、认证权限、表单层、ORM、CSRF/会话防护，代价是”约定重、自由度低”——你不太可能在 Django 里写一个纯异步高并发 API 服务，异步文档承认 ASGI 和 async def 视图可用，但 ORM 层的异步支持至今不完整。社区里”Django vs FastAPI”的对比文章（如 Django vs FastAPI in 2026）结论也趋同：CRUD、内容型、需要权限体系的业务选 Django 更快；纯 API、高并发、WebSocket 重的场景 FastAPI 更顺手。

适合谁，不适合谁。 适合：内容管理系统、后台/运营平台、数据录入型 Web 应用、需要长期维护（三到十年）的 Python 项目，以及希望”安全更新有人管”的团队——这次一天发三版就是证据。不适合：追求极致启动速度和冷启动成本的 Serverless 短函数、纯异步实时服务、以及想用最新 Python 特性（Django 6.x 只支持到 Python 3.12+ 的既定路线）又不愿等 LTS 的激进团队。

下一步可以做的三件事：一、跑一句 pip show Django 或看 requirements，如果还在 5.1 及以下（已于 2025 年 12 月 3 日结束支持），优先升到 6.1.2；5.2/6.0 用户也应立即升到 5.2.18/6.0.9，补丁版 100% 兼容。二、跨大版本升级用 django-upgrade 自动改写旧代码，它已内置 6.0 的五个 fixer。三、想判断”值不值得押注”，就去看 2026 年问卷并顺手填一份——2028 年版本号换轨后，社区的采用结构会是最早能观察到的信号。