tp框架

第一次用ThinkPHP是框架在2013年，一个外包公司丢过来半成品项目，框架代码里到处都是框架$this->assign()和$this->display()。那会儿刚写完原生PHP的框架商城系统，看到这种写法觉得挺新鲜——模板变量不用手动echo，框架控制器里一行代码就能搞定。框架但也就仅此而已了。框架

TP最让人记住的框架其实是它的中文文档。国内框架里，框架能把文档写得让新手看得懂的框架，ThinkPHP排第二没人敢排第一。框架快速入门那章从下载到跑通Hello World，框架配图加代码，框架步骤细到令人发指。框架我见过不少培训班出来的框架开发者，第一次接触MVC就是通过TP的文档。这不是什么值得吹嘘的事，但确实降低了PHP入门的门槛。

不过门槛低和好用是两码事。TP3.2时代，D()和M()两个函数让很多人分不清模型和逻辑层的边界。项目小的时候无所谓，代码量一上来，控制器里塞满业务逻辑，模型层只剩个空壳。有个朋友接了个二手项目，打开Application/Home/Controller/IndexController.class.php，三千多行，全是if-else。他说那一刻想把键盘砸了。这种情况在TP项目里不算罕见，框架给了太多自由，自由过头就是混乱。

TP5重写之后变化很大。命名空间、Composer支持、路由独立，看起来像是要跟现代PHP接轨。但实际用起来，think命令行工具生成的控制器骨架还是那个味道，fetch()替代了display()，本质没变。有个细节挺有意思：TP5的配置文件从数组改成了Config::set()，但很多老项目迁移时直接保留了原来的config.php，框架也兼容。这种向后兼容的妥协，说明官方清楚自己的用户群体在哪。

性能一直不是TP的强项。同样一个接口，Laravel可能跑200ms，TP能跑到150ms，但换成Hyperf或者Swoole系框架，直接压到50ms以下。差距不在框架本身，在于TP的请求生命周期里做了太多隐式操作。比如每次请求都要重新加载配置、重新注册别名，这些在常驻内存的框架里根本不存在。有个做物联网的朋友，设备上报接口用TP6写的，QPS到800就上不去了，换Workerman重写后轻松过万。他没说TP不好，只是场景不对。

但话说回来，TP在国内中小企业的生存土壤很厚。虚拟主机、宝塔面板、一键部署，这些环境里TP的适配度最高。你让一个只会FTP上传的运维去配Laravel的storage目录权限，他能跟你急。TP的runtime目录权限问题虽然也烦人，但至少报错信息是中文的，百度一搜就有答案。这种“土生土长”的便利性，是其他框架给不了的。

去年看TP6的源码，发现它开始用think\facade做静态代理，容器绑定的写法也向Laravel靠拢。但中间件那块还是自己的风格，app\middleware.php里注册全局中间件，跟Laravel的Kernel.php完全两回事。有个从Laravel转过来的同事，第一次写TP中间件时找了半天handle方法的$next参数，最后发现TP的写法是return $next($request)，跟Laravel一模一样，只是文档没写清楚。他骂了一句，然后继续写。

TP8已经出来了，PHP版本要求8.0+。我还没在实际项目里用过，但看更新日志，主要是修修补补。这个框架已经过了大刀阔斧改动的阶段，剩下的就是维护和兼容。对于新项目，除非团队里有人特别熟悉TP，否则我一般建议直接上Laravel或者Hyperf。但如果是维护老系统，或者给传统企业做内部工具，TP依然是个省心的选择。它不优雅，不高效，但足够熟悉，熟悉到你可以闭着眼睛写出增删改查。

这大概就是TP的定位：不是最好的框架，但可能是最不让人意外的框架。