ThinkPHP 5.1 已停更五年：四个分支该升该留的判断表
ThinkPHP 5.1 的安全更新在 2021 年 1 月到期，6.0/6.1 在 2024 年 10 月到期，8.0 的窗口在 2026 年 6 月结束，8.1 是当前主线。本文按官方版本表梳理四个分支现状，给出四种情形的升级判断、六项核对清单与参考工期。
ThinkPHP 5.1 的官方安全更新在 2021 年 1 月就到期了，6.0 与 6.1 在 2024 年 10 月也走完了窗口，8.0 的维护期在 2026 年 6 月结束，当前主线是 8.1。四个分支分别站在什么位置、手上的项目该升还是该留，这篇用官方版本表把账算清楚。
官方版本表已经把答案写好了
判断一个框架分支还能不能留，看的不是论坛里"还能不能跑"的讨论，而是官方公布的维护窗口。ThinkPHP 官方文档的版本表列出了每个分支的发布时间、BUG 修复截止和安全更新截止，这是判断风险起点的公开依据。
| 分支 | BUG 修复截止 | 安全更新截止 | 现在的处境 |
|---|---|---|---|
| 5.0（2016 年 9 月发布） | 2019-01-01 | 2020-01-01 | 官方停止更新，含安全更新 |
| 5.1（2018 年 1 月发布） | 2020-01-01 | 2021-01-01 | 官方停止更新，含安全更新 |
| 6.0 / 6.1 | 2024-10-24 | 2024-10-24 | 同一大版本、同一周期，已转入 LTS 维护 |
| 8.0（2023 年 6 月发布） | 2025-06-30 | 2026-06-30 | 功能仍在，安全窗口已到期 |
| 8.1（2024 年 11 月发布） | 官方尚未公布 | 官方尚未公布 | 当前主线，8.1.4 兼容 PHP 8.5 |
官方在 6.1.3 与 6.0.15 的发布说明里写明"6.0 及 6.1 版本将会停止功能更新，纳入 LTS 版本维护计划"，同时注明"6.0 之前版本官方不再更新和维护，包括安全更新"。这句话的分量在后半句：不是不修功能，是连安全补丁也不再由官方出。
版本节奏也要一起看。8.1 于 2024 年 11 月 21 日发布，2026 年初发布的 8.1.4 已经兼容 PHP 8.5，并配套 ThinkORM 4 的模型层改动；8.0 分支在 2024 年 7 月的 8.0.4 之后没有新版本发布。换句话说，8.0 的项目现在处在一个"能跑、但没有新补丁"的状态，而 8.0 到 8.1 是官方说明的平滑升级路径。
影响谁：三类项目，风险节奏不一样
存量 5.1 老站是首先要正视的一类。风险往往不是框架本身出漏洞，而是运行环境先动：主机商把 PHP 默认版本抬到 8.x，5.1 时代的模板语法、扩展和第三方库会先出兼容问题，之后才是安全问题。很多企业站是"能打开就不动"，直到某天后台登录不上、表单提交报错，才发现问题早就埋下了。
6.0 与 6.1 的项目刚过窗口。这类系统多数跑在 PHP 7.4 或 8.0 上，短期不会坏，但生态在往前走：新发布的扩展包逐渐不再兼容 6.x，composer update 会越来越难做。它的风险形态是"维护成本缓慢上升"，而不是"突然崩掉"，所以常被排在需求列表末尾。
8.0 的项目看起来风险低，其实容易被忽略。功能没停、文档还在，但官方安全更新在 2026 年 6 月到期，距今已过去数月；升级到 8.1 又属于框架内的小版本平移，改造面有限。这类项目继续观望的时间成本，通常高于直接升级的投入。
一个够用的风险判断方法：看三个信号——框架还有没有官方安全更新、PHP 运行时是否仍在官方支持期内、composer 依赖能否正常更新。三个里有两个亮红灯，就值得排一次升级评估，而不必等到出事。
判断表：四种情形对应四种动作
同样是"老框架"，处理方式差别很大。按业务重量而不是按版本号决定动作，通常更省钱。
| 情形 | 判断 | 建议动作 | 参考工期 |
|---|---|---|---|
| 5.1 只做展示的企业官网 | 业务逻辑轻，风险集中在环境兼容 | 优先评估按 8.x 重写，不做跨代硬升 | 2–4 周 |
| 5.1 且带会员、支付、订单 | 涉及资金与个人信息，补丁缺口不可接受 | 按官方路径 5.1 → 6.1 → 8.1 分两步走 | 4–8 周 |
| 6.0 / 6.1 后台或管理系统 | 刚过窗口，扩展生态仍在跟进 | 先升到 8.1，再统一 PHP 运行时版本 | 2–4 周 |
| 8.0 在建或在跑项目 | 安全窗口已到期，升级路径明确 | 直接升 8.1，按小版本做回归 | 3–8 人日 |
如果决定升级，先别写代码，把下面六项核对完再排期：
锁定现状：归档当前的 composer.json 与 composer.lock，记录框架版本、PHP 版本、扩展清单，后面每一步都以这份清单为基准。
把 PHP 版本写进运维文档：不要让它由主机商的面板默认值决定，升级前后都要有明确版本号。
逐个确认第三方扩展：支付、短信、上传、图片处理这类强依赖，先查有没有支持 8.x 的版本，缺一个就可能卡住整个升级。
单独过一遍模板与路由：5.x 的模板标签、6.x 的路由写法在 8.x 都有差异，这部分改造量往往被低估。
评估模型层：8.1 配套 ThinkORM 4，实体模型与视图模型的用法有变化，涉及复杂关联查询的项目要提前试。
准备可回滚环境：升级在独立分支和独立数据库副本上做，保留一套可切回的生产环境，验证通过再动线上。
这六项里，前三项决定"能不能升"，后三项决定"升完会不会出事"。实际项目里，升级受阻的原因多数不是框架本身难改，而是依赖清单没摸清、回滚方案没准备。
成本、周期与取舍
以下是参考区间，不含服务器、备案等外部成本，具体以项目二次开发量为准：8.0 升 8.1 属于常规维护升级，开发 1–3 人日，加上测试与灰度观察，整周期通常在 3–8 人日；6.1 升 8.x 涉及路由、验证、模板适配，常见 2–4 周；5.1 升 8.x 官方建议先到 6.1 再到 8.x，实务中还要处理模板引擎与老扩展，2–8 周不等。
不升级同样有成本，只是不出现在报价单上：安全事件后的应急处置、渗透测试与等保测评时被问到框架版本、每次改功能前开发先花时间做兼容验证。这部分支出平时看不见，出事时一次结清。
取舍标准可以很朴素：这套系统还打算用三年以上，就值得按目标版本重排一次；如果一年内会被替换，做收敛到够用的加固——收紧入口、限制后台访问、加一层 WAF——比大改更划算。判断依据是业务寿命，不是版本新旧。
尊云科技处理 PHP 项目时按这条路径走：先核版本与依赖现状，再决定升级还是重写，工期和风险写进方案再动手，不做"先升了再说"的尝试。站内还有一份 PHP 8 各版本维护时间表可以对照着看运行时这一层；如果评估结论是重做，也可以从企业网站开发和PHP 开发服务两页了解交付方式与范围。
数据来源：ThinkPHP 官方文档《版本选择》维护表、官方 6.1.3 与 6.0.15 发布说明、8.1.4 发布说明，版本号与发布日期以 Packagist 与 GitHub Releases 记录为准（检索时间 2026 年 10 月）。版本周期可能随官方公告调整，升级前请再核对一次官方页面。
