1.2 版本演进与特性对比

1.2 版本演进与特性对比

上一节把框架定位讲清了，这一节往地图上补另一根坐标：版本。ThinkPHP 的教程与问答在网上存量巨大，但相当一部分基于 5.x 甚至 3.x，照着旧教程写新项目会处处碰壁。读完本节，你应当能一眼分辨手头资料属于哪一代，并能为自己或团队给出明确的版本选择与升级路线。

一、为什么版本问题在 ThinkPHP 上格外突出

多数框架也有新老版本，但 ThinkPHP 的特殊之处在于：它的几代大版本之间不是「功能递增」，而是「骨架重造」。3.x 到 5.x 重写了路由与 ORM 的核心；5.x 到 6.x 干脆换了整个底座——从自带一切的单体框架，变成严格遵循 Composer 与 PSR 规范的现代框架。这意味着旧教程里通篇正确的代码，在新版本里可能连目录都不存在了。把代际脉络搞清楚，你读任何一篇旧资料时都能自动换算：「这篇讲的是哪一代的哪座站台，新版本里它搬到了哪里」。

图 1-2：版本演化时间线与关键改造

二、三列对比：5.x、6.x、8.x 差在哪

下表按你在实际项目里最常撞到的维度对比。建议的读法是竖着读一列——把 5.x 那列读完，你就明白旧教程「哪里不对劲」；把 8.x 那列读完，你就知道自己要建立的心智模型长什么样。

⚠️ 常见坑：搜索引擎排前头的 ThinkPHP 教程不少是 5.x 时代的。分辨办法很省事——看安装命令：让你去官网下载压缩包的基本是旧代；给 composer create-project topthink/think 命令的才是 6.x 之后。

三、代码里的代际差异：两段对照

空说差异没感觉，看两段真实的对照。第一段是 5.x 时代常见的控制器写法，静态调用满天飞，助手函数直进直出：

// 5.x 风格：助手函数 + 静态调用，能跑但依赖全局状态
namespace app\index\controller;

use think\Controller;
use think\Db;

class Book extends Controller
{
    public function detail($id)
    {
        // Db 门面直查，模型层形同虚设
        $book = Db::name('book')->where('id', $id)->find();
        // view 助手函数直接渲染，参数散落在方法各处
        return view('detail', ['book' => $book]);
    }
}
​

第二段是同样的业务在 6.x/8.x 下的写法：控制器继承统一的基础类，模型通过类型提示注入，业务交给模型层，响应显式声明：

// 8.x 风格：依赖注入 + 模型分层，对象关系清楚
namespace app\controller;

use app\model\Book;
use app\BaseController;
use think\Response;

class Book extends BaseController
{
    // 容器自动装配 Book 模型，控制器不关心它怎么造出来
    public function detail(int $id, Book $book): Response
    {
        $data = $book->findOrEmpty($id);
        return json(['code' => 0, 'data' => $data]);
    }
}
​

对照的结论不是「5.x 不能跑」，而是依赖关系全然不同：旧写法里控制器直接拽全局的 Db，单元测试很难替身；新写法里模型从容器注入，随时可以换成测试替身。第 2 章讲容器时你会再见到这对例子，届时「为什么」会完全展开。

四、怎么选：三条决策路线

路线一是新项目：直接 8.x，没有历史包袱就不用讨论。PHP 环境提前确认 8.0 以上，虚拟主机或老旧运维体系撑不起 PHP 8 时再退回 6.x，这属于少数情况。

路线二是存量 6.x 项目：可以升级 8.x，但先做收益评估。官方为升级提供了指导与工具，大多数业务代码改动有限；真正的工作量通常在依赖的第三方扩展包是否都有 8.x 兼容版本。先跑通测试用例、再升依赖、再升框架，顺序别乱。

路线三是存量 5.x 项目：把「升级」从选项里划掉，这个量级接近重写。务实的做法是新旧并行——旧系统原地维护，新功能用 8.x 起新服务，中间用接口或数据同步衔接，按模块逐步搬家。

五、动手练习：查清你的资料的代际

背景：你在网上找到一篇《ThinkPHP 手机号验证教程》。操作：打开文中任意代码段，按三条特征定代际——代码里有没有 namespace app\index\controller 这种带模块层的命名空间（5.x 特征）；安装方式是压缩包还是 Composer；验证码、Session 用法是助手函数风格还是对象注入风格。结果示例：看到 app\index\controller 与压缩包安装，基本可判定 5.x。解读：此时你有两种选择，一是弃文，二是换算——把它的思路（比如验证逻辑本身）留下，API 查当前版本手册重写。变式：把公司里某个老模块的代码拿来做同样的定代际练习，写三行结论给带你的同事看，他能当场指出你判断里的问题。

六、一个真实的选型现场

把决策路线放到一个具体场景里走一遍：接手一个五年前的 5.0 老系统，甲方要求加一个小功能。第一反应是升级吗？不是——先问业务诉求与停机窗口：小功能按 5.0 的写法两小时完工，升级要两周加回归测试，显然就地维护更划算；反过来，如果这次需求是「重构订单模块并计划未来两年持续迭代」，那带着新模块一起迁到 8.x 才是正解，否则新代码写的还是旧架构，债务越滚越大。这个现场说明版本决策的输入从来不是「版本新旧」，而是「这次改动的生命周期有多长」。

本节要点回顾

• 代际即骨架：ThinkPHP 的大版本是重造而非递增，读旧资料前必须先定代际。
• 6.x 是分水岭：Composer 化、容器、中间件、PSR 从这一代定型，8.x 在其上要求 PHP 8 并持续清理废弃用法。
• 识别旧教程：压缩包安装、带模块层的命名空间、助手函数直查数据库，是 5.x 资料的典型指纹。
• 升级路线：新项目直上 8.x；6.x 升 8.x 先评依赖再动手；5.x 不升级，走新旧并行逐步搬家。
• 对照读法：5.x 与 8.x 的控制器写法差异，本质是「全局直拉」与「容器注入」的依赖关系差异。

下一节动手装环境：把 PHP、Composer 与项目骨架落在本机上，并沿目录结构认一遍总线站台。