搜一个方法名，点进文档，把示例代码贴进项目，跑起来报错。回头仔细看才发现那份是 5.0 的文档，项目用的是 5.1。这两套的差别不是小修小补。

5.0 和 5.1 是两套文档

官网文档区按版本分开，进页面前先看地址栏里的版本号。5.0 的配置集中在 application 下的 config.php，5.1 拆成 config 目录，还能按模块覆盖。路由文件 5.0 是 route.php，5.1 变成了 route 目录下按文件组织。照错版本文档写，最常见的结果就是配置写了不生效。

手册里值得先读的四章

路由、数据库、模板、验证。路由决定 URL 怎么进控制器，也是出安全问题最多的地方；数据库章节要分清查询构造器和模型两套写法，别混着用；模板看变量输出和转义规则；验证看场景和批量验证。其余章节用到再查，通读一遍记不住。

文档和代码对不上时

先确认 vendor 下 think 框架的实际版本，composer show 能直接列出来。文档写的是大版本行为，小版本之间也可能调整。对不上就翻框架源码，方法签名和默认参数都在里面，比任何二手文章都准。

助手函数最容易踩坑。同名函数在不同版本里参数顺序变过，从旧项目复制来的调用看着一模一样，跑起来报参数错误。碰到这种，直接在 vendor 目录里搜函数定义，看三个参数哪个在前。

目录结构对不上，先怀疑版本

同事发来的代码，如果看到 config 是个目录，基本就是 5.1 以后的版本；根目录只有一个 config.php，多半是 5.0。这种一眼能辨的特征比翻 composer.json 快，先把版本对上再查方法。

手册里的示例用了某个类，项目里却没有，先看 use 语句引的命名空间对不对。命名空间写错时报错信息往往指向别处，很容易被带偏。

本地留一份离线文档

把对应版本的文档拉到本地跑起来，断网也能查，搜索还快。项目里如果有二次封装的基类，顺手在旁边记一份自己的约定，新人接手能少问一半问题。

版本号写进 README，比什么注释都管用。三年后回来维护的人，第一件想知道的就是这份代码跑在哪个版本上。