企业官网建设流程全解析

简介：ThinkPHP 3.1.3完整版是一套遵循模型-视图-控制器设计模式的国产开源框架，面向掌握基本语法、希望深入理解框架运作机制的开发者，也适合课程设计或小规模项目直接使用。压缩包为zip格式，仅一点三七兆字节，内部为完整的框架目录，包含核心库、配置样例、模板引擎及数据库驱动等源码文件，下载后解压并配置环境即可运行，省去逐文件收集的麻烦。目前已有二百八十人学习下载，这一经典版本仍可作为理解现代框架演进的重要参考。借助这份完整包，可以实际演练路由规则、控制器与模型的交互、基于ActiveRecord的数据操作、错误日志记录，以及文件、内存或Redis等缓存策略；同时框架内置的输入过滤和SQL注入防范设计，能帮助读者建立更规范的安全编码意识。对于后续升级到更高版本或迁移至其他框架，这份完整源码也是很好的比照蓝本。

1. 为什么还在聊ThinkPHP 3.1.3这套老框架

先说个场景：你在维护一个2013年前后上线的老项目，或者接手了一个外包转包好几手的二手系统，打开服务端代码一看，ThinkPHP框架目录躺在那里，版本号写着3.1.3。这时候你会觉得亲切还是头疼？我猜测多半是头疼，因为这个版本夹在2.x和3.2之间，网上能搜到的资料本来就少，能匹配到完整版的资源更是稀缺。

但说句公道话，ThinkPHP 3.1.3在当年是一套非常完整的PHP开发框架。它把MVC分层、ORM映射、模板引擎、缓存机制、路由解析这些核心能力都打包好了，目录结构清晰，惯例优于配置，对中文开发者极其友好。那时候做一个CMS、企业站、电商系统，用它开发效率确实很高，官方文档和社区活跃度也都在线。时至今日，仍有一批存量项目跑在这个版本上，不是说换就能换的——数据表结构、业务逻辑、接口协议可能都深度绑定在框架的约定里，贸然升级到3.2或者5.x，改动成本不亚于重写。

这篇博文就围绕ThinkPHP 3.1.3 Full完整版展开，聊清楚这个完整包的特殊价值、内部结构、部署要点和实际维护中踩过的坑。无论你是刚接手老项目的新人，还是想搞明白这个老版本完整版到底比普通版多出什么东西的开发者，下面这些内容都能给你节省大量摸索时间。

2. 完整版到底“完整”在哪里

2.1 核心目录结构的内在逻辑

解压ThinkPHP 3.1.3_Full完整版之后，你会看到一套带全量资源的目录树。很多人习惯直接把它丢进Web根目录就跑，但如果不理解目录设计的意图，遇到问题会非常被动。这里先看最核心的部分：

ThinkPHP/ ├── ThinkPHP/ │ ├── Common/ │ ├── Conf/ │ ├── Extend/ │ ├── Lang/ │ ├── Lib/ │ │ ├── Behavior/ │ │ ├── Core/ │ │ ├── Driver/ │ │ ├── Model/ │ │ ├── Template/ │ │ └── Think/ │ ├── Tpl/ │ └── ThinkPHP.php ├── Home/ │ ├── Common/ │ ├── Conf/ │ ├── Lang/ │ ├── Lib/ │ ├── Tpl/ │ └── index.php └── index.php

外层是项目目录，内层是框架核心目录。ThinkPHP/ThinkPHP.php是整个框架的启动入口，入口文件通过引入它完成初始化。Lib/Core目录存放框架的核心类，包括App.class.php（应用调度）、Action.class.php（控制器基类）、Model.class.php（模型基类）等，这些是运行任何应用都少不了的骨架。

真正的区别在于Extend和Driver这两个目录。完整版把大量扩展驱动都带上了：Driver/Db下面有Mysql.class.php、Mysqli.class.php、Pdo.class.php、Sqlite.class.php等数据库驱动；Driver/Cache下面有File.class.php、Memcache.class.php、Redis.class.php、Xcache.class.php等缓存驱动；Driver/Template下面有Smarty.class.php等模板引擎驱动。这些驱动在实际项目里未必全部用得到，但它的价值在于：开发环境里你不需要临时去下载驱动文件，切换到不同数据库或者缓存方案时，配置改一下就能跑通。

2.2 与精简版、普通版的差异

ThinkPHP官方在3.x时代经常出三种形态的发行包：精简版、普通版、完整版。精简版砍掉了几乎所有扩展和驱动，只保留核心的运行能力，适合对包体积敏感或者只跑简单应用的场景；普通版携带常用驱动和基础扩展；完整版则是全量打包，连第三方类库、行为扩展、模板标签扩展都包含在内。

有人觉得完整版体积大、加载慢，其实这个担心有些多余。因为ThinkPHP采用惰性加载机制，ThinkPHP.php启动时只加载核心基础类，具体某个驱动或者扩展类只有在你真正调用到的时候才会被include进来。所以磁盘上多出来的这些文件，对运行期性能几乎没有任何影响。反而在排查问题的时候有个好处：当代码里用到某个类报“类不存在”的错误时，你能直接在本地框架目录里检索到这个类文件，快速确认是被误删了还是路径写错了。

3. 本地环境搭建与部署实操

3.1 运行环境兼容性问题排查

做老框架部署，第一步往往不是写代码，而是确认PHP环境是否兼容。ThinkPHP 3.1.3官方推荐的是PHP 5.2以上、PHP 5.3以下的运行环境，但2025年的今天，谁机器上还会装PHP 5.2？大多数人的本机环境是PHP 7.4、PHP 8.0甚至更高。这就会遇到几个明显问题。

PHP 7+已经移除的mysql扩展（注意不是mysqli），会被代码中形如mysql_connect()的老式调用触发致命错误。好在这套框架使用的是PDO或mysqli驱动，只要你在Conf/config.php中把数据库连接方式配置成DB_TYPE => 'mysqli'，框架内部就不会调用mysql_*函数。

第二个坑是PHP 7+对构造函数写法的严格处理。老版框架中，如果模型类里定义了与类名同名的方法作为构造函数，在PHP 7里会抛出一个废弃警告（deprecated）。3.1.3的框架核心已经改成了__construct写法，但你自己写的业务模型如果沿用古早风格，就需要逐一改过来。

第三个是ext-json扩展缺失的问题。PHP 7.x某些编译版本默认没有启用json扩展，而ThinkPHP的很多地方——比如数据返回、json_encode操作、参数解析——都依赖json相关函数。如果你在运行时报“Call to undefined function json_encode()”，基本可以断定是json扩展没装。处理方式要看具体环境：Windows下在php.ini里取消extension=php_json.dll前的分号注释；Linux下通过apt install php7.x-json或者yum install php-json重新编译安装。这个在Composer部署场景中尤其常见，因为Composer检查依赖时会直接报“requires ext-json”，思路是一样的。

3.2 完整部署步骤记录

下面是我在新接手一台Linux服务器、准备把ThinkPHP 3.1.3项目跑起来时，实际操作过的部署步骤。这里用的是Apache + PHP 7.4组合，系统是Ubuntu 20.04。

第一步，把完整版压缩包解压到Web根目录后，先给运行时目录加权限：

unzip ThinkPHP3.1.3_Full.zip -d /var/www/html/ cd /var/www/html/ThinkPHP chmod -R 777 Runtime/ # 框架的运行时目录，必须可写 chmod -R 777 Home/Runtime/

有些项目的日志文件、缓存文件直接写在Runtime下面，权限不够就是白屏或者报缓存目录不可写的错误。这里建议给755，如果服务器配置特殊再放宽。

第二步，配置虚拟主机，把站点根目录指到项目根目录，并开启mod_rewrite，否则URL重写模式走不通：

<VirtualHost *:80> ServerName thinkphp.local DocumentRoot /var/www/html <Directory /var/www/html> Options FollowSymLinks AllowOverride All Require all granted </Directory> </VirtualHost>

然后执行：

a2enmod rewrite service apache2 restart

第三步，修改数据库配置。在Home/Conf/config.php中，需要注意DB_DSN、DB_HOST等参数是否和本地数据库保持一致。一个常见的坑是：老项目在config.php里配置了DB_PWD为某个历史密码，但本地MySQL用的是socket认证，PDO连接时可能报Access denied for user。这时最简单的做法是确保创建一个和线上同名的数据库用户，或者临时把配置改成root用户方便排查。

第四步，访问http://thinkphp.local/index.php/Home/Index/index，如果看到欢迎页或者项目首页，部署就完成了。

4. 核心功能实操：路由、控制器、模型与模板

4.1 URL解析与路由配置

ThinkPHP 3.1.3默认采用PATHINFO模式，URL形如/index.php/Home/User/show/id/1。这种模式下，Home表示分组（模块），User表示控制器，show表示操作（方法），后面的id/1是参数键值对。理解这条链路，对后面排查404问题很有帮助。

如果部署后访问非首页URL出现404，基本集中在两个原因：一是Apache的mod_rewrite没开启，路由重写规则没生效；二是入口文件中PATHINFO模式未正确解析。你可以在入口文件里临时开启调试模式来看详细错误：

// index.php define('APP_DEBUG', true);

打开调试后，页面上会输出框架的加载过程和数据库SQL语句，能快速定位是控制器方法名写错，还是参数解析失败。这里多提一句，3.1.3的URL模式支持URL_MODEL配置，取值0、1、2分别对应普通模式、PATHINFO模式、REWRITE模式。如果伪静态规则没配好，最稳妥的方式是先用普通模式（?m=Home&c=User&a=show&id=1）跑通业务，再切换到优美模式调整重写规则。

4.2 控制器的标准开发姿势

控制器继承框架的Action类，一个典型的控制器写法如下：

<?php class UserAction extends Action { public function show() { $id = (int) I('get.id'); // 获取get参数id $user = M('User')->find($id); $this->assign('user', $user); $this->display(); } }

这里有个经常被新同学问到的函数：I()。它是3.1.x版本提供的统一输入过滤器，用法是I('get.id')、I('post.name')、I('request.type')。相比直接操作$_GET、$_POST，它多了默认值设置和过滤处理，比如I('get.id', 0, 'intval')表示从GET取id参数，取不到时默认0，同时用intval过滤。这能在源头减少SQL注入和XSS风险。

实际操作中，我见过一些老代码习惯直接写$_GET['id']，这也不是不能用，但框架既然提供了统一入口，建议逐步迁移。尤其是老项目要做安全加固的时候，把散落的超全局数组改成I()方法是一本万利的事。

4.3 模板引擎的使用要点

3.1.3自带一套模板引擎，模板文件放在Home/Tpl目录下，默认以控制器名分目录。模板语法上，{$user.name}输出变量，<volist name="list" id="vo">遍历数组，<if condition="$vo.status eq 1">做条件判断。

这套模板引擎有一个特性：模板文件会被编译成PHP文件并缓存在Runtime/Temp目录。所以当你修改了模板内容，但刷新页面发现没有变化时，多半是缓存没清。手动删除Runtime/Temp下的文件，或者开启模板调试模式TMPL_CACHE_ON => false，就能解决。这个问题在完整版部署后特别常见，因为自带示例模板首次访问后生成了缓存，后续改动模板经常被这个坑绊住。

模板继承机制在这个版本里还比较原始，用的是<include file="header" />这种引入方式。布局页面LayOut的概念和3.2+也不太一样，碰到复杂页面复用可以先抽公共文件做include，这是最低成本的方案。

5. 老项目维护中的排查技巧与实战总结

5.1 高频报错速查表

我在多个ThinkPHP 3.1.3老项目上处理过问题，整理了一张高频报错速查表，按照错误现象快速定位问题原因和修复方向。

5.2 环境升级时的一个隐蔽陷阱

如果说上面都是小打小闹，下面这个场景才真正让人头疼。把项目从PHP 5.4迁移到PHP 7.4时，很多看起来正常的代码会突然报错。比如preg_replace()函数的/e修饰符在PHP 7.0开始被彻底删除了，而老项目的模板引擎或者某些第三方类库中可能用到了这个写法。

ThinkPHP 3.1.3核心层在3.1.3版本中已经移除了preg_replace的/e用法，但你自己从网上复制的某个分页类、上传类或者后台插件里有可能残留这些代码。处理办法是全文搜索preg_replace(.*?\\/e，把使用/e修饰符的正则改成preg_replace_callback方式，虽然改动量不小，但这是迁移到新PHP版本的必经之路。

另外一个隐蔽问题是mysql扩展换成mysqli或PDO之后，某些框架底层方法返回的数据类型会发生变化。比如mysql_query()的返回值类型和mysqli_query()不同，可能影响到循环遍历的逻辑。框架层已经把数据库操作封装好了，业务代码中直接调M()、D()的话问题不大，但使用了原生SQL工具类的地方就要逐一验证结果集。

5.3 安全加固与老项目的共存之道

老版本的框架在安全性上天然弱于新版，这是事实。但项目不能因为框架老就直接放弃维护，实际工作中我采取的是组合策略。

输入过滤走框架的I()方法，同时给公共入口文件加上全局过滤规则。可以在Common/common.php中统一拦截处理，比如对所有页面做SQL关键字过滤、HTML转义等。输出侧，在模板里对动态拼接的字符串做htmlspecialchars处理，避免反射型XSS。

文件上传是一个重点检查项。3.1.3自带的上传类允许配置文件后缀、大小限制，但旧版默认配置里危险后缀可能没关严。建议检查上传配置，把php、phtml、pht等脚本后缀强制拒绝，上传目录禁止脚本执行权限。这个操作在Apache下可以用目录级.htaccess实现，Nginx下通过location配置实现。

还有一个容易被忽视的点：后台入口地址不要使用默认的/Admin、/index.php/Admin/Login/index这种路径。我习惯在入口文件里加一个简单的访问令牌验证，比如通过自定义路由或者额外参数跳转，把真正的后台入口藏起来。这个算不上高深防护，但能挡掉大量扫描器的无差别攻击。

5.4 从老框架迁移到一个平滑路径

如果团队决定给这个老项目寻找出路，我的建议是不要试图一步到位重写新框架。先梳理项目的路由规则、数据库操作、模板标签使用的是哪些语法，然后评估哪些业务逻辑可以直接复用，哪些必须重写。

ThinkPHP 3.1.3到3.2.x的升级相对平滑，很多业务类和模板文件可以小改后复用；直接跳到ThinkPHP 5.x或者6.x则变动非常大，不仅命名空间机制完全不同，请求生命周期、验证器、ORM的实现都有颠覆性差异。更稳妥的路线是先把服务器环境和数据库迁移到新版本，让老框架稳定运行，再逐步把核心功能拆分成新框架的模块，通过同一个域名、不同的URL前缀做灰度过渡。

这种渐进式迁移最大的好处是风险可控，每个阶段的改动都能独立回归，不会出现一次性全部重构导致项目瘫痪的情况。

6. 写在最后：完整版的实际维护经验

说回ThinkPHP 3.1.3_Full完整版本身，我个人的体会是：完整版的价值不在于它让你少下载几个驱动文件，而在于它保留了一个时代PHP开发的最佳实践样本。你能在这个包里看到框架作者对MVC分层、数据库抽象、模板引擎、缓存体系的设计思路，这对理解后续所有ThinkPHP版本甚至其他PHP框架都很有帮助。

如果你正在维护一个基于这套框架的老系统，记住几个原则：优先保证日志可查，遇到问题先看Runtime日志和Web服务器错误日志；配置修改后记得清缓存；改动模板前先备份；尽量不要在当前环境上升级PHP大版本，除非你有完整的回归测试方案。

最后分享一个实际操作中的小技巧：完整版里自带的README文件有时会因为编码问题在Windows记事本里打开乱码，内容不全，但如果你需要确认该版本包含的文件清单，可以直接看压缩包根目录下的文件时间戳，或者查看框架ThinkPHP.php里的THINK_VERSION常量，这个常量值能精确告诉你是哪个小版本，避免和网上流传的其他版本混淆。希望这篇分享能帮你在处理老框架项目时少踩几个坑。

本文还有配套的精品资源，点击获取