2026年4月7日django团队发布的安全公告里，直接点出了很多老项目早就有预感但不想面对的事实：随着6.0.4、5.2.13和4.2.30三个版本同步推送，django 4.2正式走到扩展支持的终点。官方也没绕弯子，所有还在运行4.2版本的用户，得尽快升级到5.2或更高版本，才能继续收到官方提供的安全修复补丁。

来源：Django 官方博客

这条消息的重点根本不是4.2.30又修了多少漏洞，而是官方正式官宣，以后不会再给4.2分支提供后续安全维护了。这次公告里列了多项安全问题，包括ASGI头部伪造、后台权限滥用、base64上传导致的性能退化，以及请求体内存限制绕过等。相当于4.2的最后一轮补丁不是平静收官，是把一批现实存在的漏洞处理完之后，直接告诉用户这个版本分支的维护周期彻底到站了。

手里还留着大量4.2项目的团队要注意，风险不止是以后拿不到新功能，而是后续就算再出现同类安全问题，官方也不会继续为这个分支提供例行补丁。很多组织之前把LTS长期支持版本当成长期安全垫，但这次公告直接把边界说死了：4.2的安全垫已经用完，接下来想继续留在官方支持的区间里，只能迁移到5.2或更新的版本系列。

Django

避免常见的 Django 错误——QuerySet 评估、N+1 查询、迁移冲突和 ORM 陷阱。

下载

来源：Django 官方博客

从实操迁移的角度看，这次公告其实也给出了明确的执行顺序：先把4.2.30补丁打上，确保已公开的这批问题全部得到兜底修复，再对照官方下载页和后续发布时间表，规划往5.2或6.0升级的时间窗口。真正危险的操作不是短时间内没完成升级，而是错把已经停更的4.2当成还能长期领补丁的稳定避风港，官方这次公告已经彻底终结了这个错误假设。

这类Django版本更新的判断边界，永远以Django官方博客当前公开页面标注的版本号、修补项、支持范围和限制条件为准。官方已经明确写明的内容，可以直接放进自己的升级清单，页面没有明确承诺的能力、兼容结论或默认行为，建议先做灰度验证，再决定要不要纳入团队的通用技术基线。