接手一个 2019 年上线的商城，composer.lock 里躺着 topthink/framework 5.0.24，安全扫描一跑，报告标红好几条。客户问能不能直接升到最新版，答案是不能一步到位，5.0 到 5.1 的改动就足够让项目起不来。

这个版本处在什么位置

5.0 分支早就停止功能更新，5.0.24 属于该分支后期的补丁版本。框架本身结构简单，入口文件加载 thinkphp 目录下的引导文件，路由、模型、模板引擎的写法和后面的 5.1、6.0 差别不小。官方长期维护的是 6.0 和 8.0，5.0 不在其列。

先做隔离，再谈升级

  • 关掉调试模式。配置里的 app_debug 设为 false，异常页面不再输出堆栈和路径，这一步能挡掉大量信息泄露。
  • 入口收敛。后台路径改名，关闭不用的模块，静态资源走 CDN，减少框架暴露面。
  • 前置一层网关或 WAF，把明显的异常请求挡在 PHP 之前，给升级争取时间。
  • 日志和上传目录禁止执行 PHP，这两个目录是历史上被利用最多的位置。

升级路线的实际选择

小项目、代码量不大，直接照着 6.0 的文档重写控制器和模型层，比一层层迁移更快。中等项目可以走 5.0 到 5.1，再评估是否继续。5.1 改的是目录结构和容器用法，门面类和助手函数大部分还在，改造成本可控。再往上到 6.0 需要 PHP 7.1 以上，8.0 要求 PHP 8，老服务器的 PHP 版本往往卡在这一步。

动手前把测试用例补到核心链路，至少覆盖登录、下单、支付回调。没有测试就升级，等于在线上试错。

决定不升的话怎么维持

把框架锁在一个可用的补丁版本，不改 vendor 里的代码，用 composer 的版本约束固定住。定期看官方仓库的提交记录，有新补丁就小步跟进。数据库账号按最小权限给，应用账号不要有 drop 权限，这条比任何框架层面的加固都实在。

五年以上的项目，升级的成本通常低于继续维护的成本，只是要挑业务空窗期做，别在大促前动框架。升级前把 vendor 目录和数据库各做一份完整备份，回滚时才不至于手忙脚乱。