一、为什么又写 Laravel vs ThinkPHP
在国内 PHP 圈，Laravel 与 ThinkPHP 的对比从未停息：一篇博客、一场 meetup、甚至一次面试闲聊，都能把话题点燃。有人迷恋 Laravel 的“艺术感”，有人诟病其“厚重”；有人赞赏 ThinkPHP 的“轻量快”，又吐槽“文档跳跃”。
二、理念：艺术范与实用主义的起点
Laravel 诞生之初就提出 “PHP Developers deserve beautiful code”——开发者值得优雅的代码。它大量借鉴 Rails 的“约定大于配置”，强调接口隔离、依赖注入、函数式 pipeline，甚至把“诗意”写进文档注释。
ThinkPHP 则来自一线实战：作者为了让中小型项目“写得快、上线快、维护简单”，在 2006 年发布第一版。它信奉“够用即可”，默认配置极少，目录结构一目了然，注释贴近中文表达。
一句话总结：Laravel 先考虑“扩展性与美感”，再让你“写得快”；ThinkPHP 先考虑“写得快”，再让你“兼顾优雅”。出发点不同，导致后续所有设计选择都走向不同分支。
ThinkPHP 则来自一线实战：作者为了让中小型项目“写得快、上线快、维护简单”，在 2006 年发布第一版。它信奉“够用即可”，默认配置极少，目录结构一目了然，注释贴近中文表达。
一句话总结：Laravel 先考虑“扩展性与美感”，再让你“写得快”；ThinkPHP 先考虑“写得快”，再让你“兼顾优雅”。出发点不同，导致后续所有设计选择都走向不同分支。
三、架构：重量级分层与轻量级 MVC 的对照
Laravel 采用“服务容器+服务提供者”双核心：容器负责依赖解析，提供者负责注册；任何功能（日志、缓存、队列）都被拆成独立服务，可插拔、可替换、可 mock。代价是启动时要扫描大量提供者，文件 IO 与反射缓存占用更多内存。
ThinkPHP 坚持“MVC 足够用”：一个入口文件、一个路由分发、一个模型层即可跑通业务。容器只是“可选工具”，而非心脏。启动流程短，默认加载更少，适合“一台虚机+一个进程”就能扛住的项目。
架构差异带来资源占用差异：同样 Hello World，Laravel 默认加载 30+ 服务，ThinkPHP 可能只加载 5 个核心类。对于 CPU 密集或内存受限环境，这是选型时必须衡量的硬指标。
ThinkPHP 坚持“MVC 足够用”：一个入口文件、一个路由分发、一个模型层即可跑通业务。容器只是“可选工具”，而非心脏。启动流程短，默认加载更少，适合“一台虚机+一个进程”就能扛住的项目。
架构差异带来资源占用差异：同样 Hello World，Laravel 默认加载 30+ 服务，ThinkPHP 可能只加载 5 个核心类。对于 CPU 密集或内存受限环境，这是选型时必须衡量的硬指标。
四、路由：资源式与控制器式的两种思维
Laravel 推崇“资源路由”——一行声明自动生成 CRUD 七条路由，URL、控制器方法、视图变量名全部按约定生成；再搭配“路由模型绑定”，URL 段直接与 ORM 实例挂钩，减少查询代码。
ThinkPHP 更习惯“控制器方法即路由”——写一个方法，路由就存在；参数通过段名或查询字符串传递，灵活但容易失控。它也有资源路由，但默认关闭，需要手动开启。
结果：Laravel 的路由文件常常是“声明式配置”，一眼就能读出业务结构；ThinkPHP 的路由文件更贴近“传统调度”，新人上手快，但项目膨胀后可能出现“同名方法、不同控制器”冲突，需要规范约束。
ThinkPHP 更习惯“控制器方法即路由”——写一个方法，路由就存在；参数通过段名或查询字符串传递，灵活但容易失控。它也有资源路由，但默认关闭，需要手动开启。
结果：Laravel 的路由文件常常是“声明式配置”，一眼就能读出业务结构；ThinkPHP 的路由文件更贴近“传统调度”，新人上手快，但项目膨胀后可能出现“同名方法、不同控制器”冲突，需要规范约束。
五、ORM：Eloquent 与 QueryBuilder 的范式差异
Laravel 的 Eloquent 强调“模型即对象”——关联、作用域、访问器、修改器、事件、观察者全部封装在模型类；再辅以“延迟加载”“预加载”“子查询”等功能，让复杂 SQL 也能用面向对象方式表达。缺点是：不熟悉 SQL 的开发者容易写出 N+1 查询；模型类庞大后，单文件上千行很常见。
ThinkPHP 的 ORM 默认是“查询构造器”思维——链式方法拼 SQL，再辅以“模型层”封装；关联查询更接近手写 SQL，学习曲线平缓，调试直观。它也有“模型事件”“访问器”，但属于“可选插件”，不强求。
一句话：Laravel 先让你“不写 SQL”，再教你“如何写高效 SQL”；ThinkPHP 先让你“写 SQL”，再教你“如何封装得更优雅”。
ThinkPHP 的 ORM 默认是“查询构造器”思维——链式方法拼 SQL，再辅以“模型层”封装；关联查询更接近手写 SQL，学习曲线平缓，调试直观。它也有“模型事件”“访问器”，但属于“可选插件”，不强求。
一句话：Laravel 先让你“不写 SQL”，再教你“如何写高效 SQL”；ThinkPHP 先让你“写 SQL”，再教你“如何封装得更优雅”。
六、测试：自带工厂与“按需测试”两种态度
Laravel 默认自带测试骨架、数据库事务回滚、模型工厂、HTTP 测试客户端；甚至为队列、事件、文件存储都提供“Fake”实现，鼓励 TDD。首次创建项目就能跑通单元测试，再逐步补用例。
ThinkPHP 测试属于“可选包”：安装扩展后才拥有数据库回滚、工厂、HTTP 客户端。它假定“很多项目并不需要单元测试”，把选择权留给团队。对于快速原型、生命周期短的项目，这确实能减少学习负担；但对于长期迭代、多人协作的产品，后期补测试的边际成本更高。
选型建议：如果团队已养成 TDD 习惯，Laravel 的能节省搭建时间；若项目以“快速交付、一次性交付”为主，ThinkPHP 的“按需引入”更轻便。
ThinkPHP 测试属于“可选包”：安装扩展后才拥有数据库回滚、工厂、HTTP 客户端。它假定“很多项目并不需要单元测试”，把选择权留给团队。对于快速原型、生命周期短的项目，这确实能减少学习负担；但对于长期迭代、多人协作的产品，后期补测试的边际成本更高。
选型建议：如果团队已养成 TDD 习惯，Laravel 的能节省搭建时间；若项目以“快速交付、一次性交付”为主，ThinkPHP 的“按需引入”更轻便。
七、生态与插件：Packagist 与自建市场的差异
Laravel 依赖 Packagist 全量生态，任何 PHP 库都能通过 Composer 一键引入；官方还提供 Horizon（队列）、Nova（后台）、Sanctum（API 认证）、Socialite（OAuth）等商业/开源扩展，形成“官方+第三方”双轮驱动。缺点是：版本更新快，第三方扩展可能出现“滞后不兼容”；需要锁定组合并做回归测试。
ThinkPHP 拥有官方 Extension Market，审核相对严格，扩展数量少而精；核心团队维护的 ORM、队列、验证、模板、缓存组件都随主版本同步发布，兼容性风险低。但“小众扩展”选择面窄，遇到冷门需求时，要自己写适配层。
总结：Laravel 像“大型超市”，商品琳琅满目，但需自己比对保质期；ThinkPHP 像“社区便利店”，SKU 少，但上架前已被店主筛选一遍。
ThinkPHP 拥有官方 Extension Market，审核相对严格，扩展数量少而精；核心团队维护的 ORM、队列、验证、模板、缓存组件都随主版本同步发布，兼容性风险低。但“小众扩展”选择面窄，遇到冷门需求时，要自己写适配层。
总结：Laravel 像“大型超市”，商品琳琅满目，但需自己比对保质期；ThinkPHP 像“社区便利店”，SKU 少，但上架前已被店主筛选一遍。
八、学习曲线：文档风格与中文社区的隐形门槛
Laravel 文档英文为主，结构清晰，示例丰富，但“幽默+诗意”的表达方式对非英语母语者有一定理解成本；中文社区以博客、视频、翻译手册形式补充，内容质量参差不齐，且版本分散。
ThinkPHP 文档原生中文，章节短小，示例直给；论坛、QQ 群、微信群活跃，提问能得到“长辈式”的逐行解答。对于刚毕业或英语基础薄弱的开发者，这种“母语亲和力”极具吸引力。
反过来，Laravel 的“英语门槛”也迫使开发者更早接触国际社区，阅读 RFC、参与 PR，长期看有利于个人技术视野；ThinkPHP 的“中文舒适区”容易让人停留在“复制粘贴即可”的阶段，需要自律去追源头。
ThinkPHP 文档原生中文，章节短小，示例直给；论坛、QQ 群、微信群活跃，提问能得到“长辈式”的逐行解答。对于刚毕业或英语基础薄弱的开发者，这种“母语亲和力”极具吸引力。
反过来，Laravel 的“英语门槛”也迫使开发者更早接触国际社区，阅读 RFC、参与 PR，长期看有利于个人技术视野；ThinkPHP 的“中文舒适区”容易让人停留在“复制粘贴即可”的阶段，需要自律去追源头。
九、升级策略：长期项目必须考虑的“隐形成本”
Laravel 每年发布一个大版本，且提供一年的 LTS（两年安全修复）。升级路径清晰：官方文档给出“增量变更”说明，还有升级工具自动替换废弃方法；但“清晰”不等于“轻松”——第三方扩展、自定义 ServiceProvider、模型事件都要回归测试。
ThinkPHP 大版本间隔更长，且“向后兼容”做得更激进：很多废弃接口继续保留别名，减少“断崖式”修改。对于“十年生命周期”的企业内网系统，这种“慢节奏”反而更友好；对于“想追新特性”的互联网产品，可能觉得“步伐太慢”。
选型提示：如果团队愿意“每年花一周时间升级+回归”，Laravel 的新特性红利更丰厚；如果希望“一旦部署，五年不动”，ThinkPHP 的兼容策略更省心。
ThinkPHP 大版本间隔更长，且“向后兼容”做得更激进：很多废弃接口继续保留别名，减少“断崖式”修改。对于“十年生命周期”的企业内网系统，这种“慢节奏”反而更友好；对于“想追新特性”的互联网产品，可能觉得“步伐太慢”。
选型提示：如果团队愿意“每年花一周时间升级+回归”，Laravel 的新特性红利更丰厚；如果希望“一旦部署，五年不动”，ThinkPHP 的兼容策略更省心。
十、适用场景：把“人、项目、生命周期”放在一起看
-
团队规模
10 人以下：沟通成本低，ThinkPHP 的“约定少、上手快”可让新手三天贡献代码；50 人以上：需要规范、测试、文档，Laravel 的“默认”更容易统一技术栈。 -
项目生命周期
原型验证→半年上线→两年重构：ThinkPHP 足够；
长期迭代→五年演进→多端复用：Laravel 的扩展生态更匹配。 -
性能与资源
嵌入式网关、IoT 边缘节点：内存 256 MB，ThinkPHP 的轻量启动更稳妥；
云原生、弹性伸缩：Laravel 的容器镜像虽大，但可通过“预加载+缓存”优化，吞吐量更高。 -
安全与合规
Laravel 默认开启 CSRF、ORM 防 SQL 注入、路由签名；ThinkPHP 需要手动启用或写规则。对于“上线即被扫描”的互联网产品，Laravel 的“默认安全”能减少低级漏洞；对于内网应用，人为规范也可弥补。
十一、常见误区与解毒剂
-
“Laravel 一定慢”
通过“路由缓存、配置缓存、OPcache、预加载”能把首页 RT 压到 20 ms 以下；慢更多是因为“开发者写了 N+1 查询”，而非框架原罪。 -
“ThinkPHP 不安全”
安全是“使用方式”问题；ThinkPHP 也提供参数绑定、CSRF 令牌、验证规则，只是默认关闭；需要团队写规范，强制开启。 -
“小项目用 Laravel 浪费”
若团队已熟悉 Laravel，用 Laravel 开发小项目反而更快——内置测试、日志、队列一步到位，无需自己搭积木；但若团队从未用过，学习成本可能超过“项目周期收益”。 -
“大项目必须用 Laravel”
大项目真正的挑战是“领域建模+测试+部署”，框架只是工具；ThinkPHP 通过引入 Composer 包、自建测试骨架，也能支撑百万级在线；关键在于“团队是否愿意投入规范”。
十二、选型路径：一张“决策树”而非“唯一答案”
-
英语阅读无障碍 + 愿意追新版本 → Laravel
-
中文环境为主 + 追求快速交付 → ThinkPHP
-
长期产品 + 多人协作 + 测试驱动 → Laravel
-
短平快原型 + 一人全栈 + 资源受限 → ThinkPHP
-
需要官方后台、API OAuth、队列 Dashboard → Laravel
-
需要自建轻量后台、极简队列 → ThinkPHP
决策后，还要写“技术选型说明书”：理由、风险、回退方案、升级节奏、测试策略，让后续维护者知道“当初为什么这样选”，而不是“拍脑袋”。
