简介:ThinkPHP6框架完整项目包,面向需要入门PHP框架或快速搭建Web应用的中级开发者,也适合已有简单PHP基础、希望了解完整工程结构的读者。基于PHP7.1+的轻量级MVC架构,覆盖依赖管理、配置加载、路由映射、视图渲染、扩展类库等核心模块,适合作为本地源码参考与二次开发起点。压缩包共594个文件,大小约807KB,以479个PHP源码文件为主体,同时包含md说明文档、json配置文件、yml持续集成脚本、stub类型定义、sql数据库脚本、env环境变量示例等工程文件,目录层级清晰,便于定位。已有1246人学习下载。通过整体梳理项目结构,可以理解从Composer依赖安装、环境配置、路由定义到控制器与模型实现的一套完整流程,也能看到第三方库管理、持续集成配置及应用扩展等实际工程做法,有助于快速建立对现代PHP项目结构的整体认知,并为后续独立开发PHP项目打下基础。
1. thinkphp6框架下载:这不是一个“下载完就能跑”的事
先讲个身边常见的场景:某开发者从官网下了 ThinkPHP 6 的压缩包,解压后放在站点目录,访问首页直接白屏,连错误提示都没有。他折腾了两个小时,最后才发现自己下的是 GitHub 上的源码包,里面根本没有vendor目录,依赖一个都没装。这是我在本地帮人排查过最多次的“下载翻车”现场。所以你搜到“thinkphp6框架下载”这个词时,真正要解决的问题不是“把文件拿到手”,而是“用正确的方式拿到一份能直接跑起来的框架”。ThinkPHP 6 从 2020 年发布后,就一直建议通过 Composer 安装,而不是靠浏览器下载压缩包。这篇文章会讲清楚三种下载方式的区别、环境前提、目录结构,以及我在真实项目里踩过的那些坑,保证你照着做能少走弯路。
2. 下载前必须确认的两个前提:PHP 版本与 Composer 源
2.1 PHP 版本检查:为什么 7.2 会被直接拒绝
ThinkPHP 6 对 PHP 版本有硬性要求,低于 7.2.5 连安装脚本都不会执行。我在实际项目里见过有人在 7.1 的老环境上硬跑 TP6,报错信息是一串诡异的语法错误,因为框架代码里用了高版本才有的语法特性。检查版本很简单,命令行执行:
php -v如果输出里显示的是PHP 7.2.5及以上版本,基本没问题。我还建议同时检查几个必须的扩展:
php -m | grep -E "pdo|mbstring|openssl|json|curl"这里php -m会列出所有已加载的扩展,grep用来筛选我们需要的那几个。TP6 的数据库操作依赖 PDO,文件上传和 HTTP 请求依赖 curl,加密相关的功能依赖 openssl,mbstring 则影响字符串处理。缺任何一个,框架可能装上了但部分功能跑不了。常见做法是缺什么装什么,在 Linux 上用apt install php-mbstring或yum install php-openssl这类的命令补上,装完记得重启 PHP 服务。
2.2 设置 Composer 镜像:国内下载不卡死的唯一办法
ThinkPHP 6 官方推荐的安装方式是 Composer,但我们国内网络拉取 GitHub 和 Packagist 的元数据经常超时。我印象很深的是有一次执行composer create-project,卡在Loading composer repositories这一步十几分钟不动,最后直接超时失败。后来我把镜像源切到国内镜像,整个过程从十几分钟缩短到两分钟。设置方法是全局修改 Composer 配置:
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/这行命令让 Composer 从国内镜像拉取包信息,而不是直接连接 Packagist 官网。-g表示全局生效,不影响单个项目;后面那串 URL 换成其他国内镜像也可以,但阿里云这个我用下来最稳定。设置完成后可以执行composer config -g -l查看当前生效的配置,确认repo.packagist那一项已经变成镜像地址,这样就放心了。
2.3 环境判断的一个常见误杀:PHP 版本没问题却装不上
有时候版本检查和扩展检查都通过了,composer create-project依然报错。我在某公司帮忙部署时遇到过一种情况:PHP 命令行版本和 Web 服务使用的 PHP 版本不是同一个。php -v显示 8.1,但apache或nginx加载的是另一个路径下的 PHP 7.4。这种情况在 Windows 上尤其常见,因为环境变量里的 PHP 和集成面板里的 PHP 是两套。排查方法是在项目根目录创建一个测试文件,用浏览器访问,看phpinfo()显示的版本和命令行是否一致。不一致时,要让命令行 PHP 切换到和 Web 服务同一套版本,否则 Composer 装完后项目运行还是报错,这个坑非常隐蔽。
3. 用 Composer 下载 ThinkPHP 6:正式项目与开发版两条命令
3.1 正式项目推荐:create-project 命令的完整用法
这是官方最推荐的方式,也是我每次开新项目必用的命令。它做的不只是“下载代码”,还会自动把vendor目录里的依赖全部装好,同时触发框架自带的安装程序。整个命令如下:
composer create-project topthink/think tp6拆开来看,create-project是 Composer 的一个特殊命令,相当于先执行git clone再自动执行composer install。topthink/think是 ThinkPHP 6 框架在 Packagist 上的包名,tp6是项目目录名,你可以改成任意合法的目录名。执行过程中你会在终端看到类似Installing dependencies from lock file的进度,等它跑完,进入tp6目录执行php think run,框架就能起一个内置的开发服务器。
这是最适合正式项目的安装方式,因为它生成的项目里自带.git目录吗?不会。create-project下载的源码包不带.git历史记录,这对大部分业务项目来说是好事,你可以直接git init开一个新仓库,不会带入框架本身的提交历史。命令执行时也可以指定版本:
composer create-project topthink/think tp6 6.1.0末尾那个6.1.0指定安装具体版本。如果不填,默认拉取当前最新稳定版。我一般不在生产环境追最新,如果团队有固定基线版本,就用这个方式锁死版本,避免某个小版本升级带来不可控的行为变化。
3.2 开发版或二次开发:用 git clone 拿到完整仓库
如果你要做框架本身的二次开发,或者想研究 TP6 内核源码,create-project就不太合适了,因为它拿到的是裁剪过的项目骨架。这时候我一般会直接从代码托管平台克隆完整仓库:
git clone https://github.com/top-think/think tp6-dev克隆完成后进入目录,手动安装依赖:
cd tp6-dev composer install这里的逻辑和create-project的区别在于:git clone拿到的是完整仓库,里面包含框架的全部历史提交、分支信息和测试代码;composer install会根据仓库里已有的composer.lock文件安装精确版本的依赖。这个方式适合想给框架提代码贡献的人,或者需要调试框架底层逻辑的场景。要注意的是,克隆下来的框架默认可能不是 6.x 的最新版本,需要自己切换分支:
git checkout 6.16.1是分支名,切换前建议先执行git branch -a查看所有远程分支,确认目标分支确实存在。这种方式不适合拿来直接做业务项目,因为仓库里有大量和业务无关的文件,还容易在后续composer update时把框架核心代码升级到一个超出预期的版本。
3.3 两种方式的结果都一样:vendor 目录才是灵魂
不管是create-project还是git clone加composer install,最终项目根目录下都会多出一个vendor文件夹。这个文件夹里存放的是所有第三方依赖,包括 TP6 的核心框架代码topthink/framework,以及各种功能扩展。很多新手会困惑:为什么官网下载的压缩包里没有vendor?因为官方源码包默认不附带依赖,需要你自己执行composer install来生成。
判断下载有没有成功,最直接的标准就是看vendor目录是否存在。后续如果执行composer update,这个目录里的内容会跟着更新。这里我有一个建议,vendor目录不需要提交到 Git 仓库,正确做法是在项目根目录创建.gitignore文件,把/vendor写进去,让每个开发者克隆代码后自己执行composer install。这样代码库体积小,也避免了不同操作系统下依赖二进制文件不一致的问题。
4. 官网打包下载与本地运行的完整步骤
4.1 官网获取源码包:适合快速体验的场景
虽然我个人强烈推荐 Composer 方式,但确实有一些场景下官网下载更方便:比如内网服务器不能访问外网 Composer 源,或者你只是想本地快速看下框架代码长什么样。官网提供的源码包是一个压缩文件,解开后就能看到完整的框架目录。不过在动手之前,你要有个心理准备:这种源码包同样不包含vendor依赖,下载完后它只能看不能跑。
如果你在内网环境,只能靠源码包离线部署,过程会比 Composer 方式繁琐一些。我一般会在有外网的机器上用create-project把完整项目装好,然后用tar或zip压缩整个目录,再传到内网机器解压。这样vendor目录被打包进去,内网机器不需要装 Composer 也能运行,这是我在某实验室部署时验证过的可靠方案。
4.2 放到 Web 服务器:入口文件与伪静态配置
源码包解压后,你会看到public目录,这是框架唯一的对外入口。我之前见过有人把项目整个放到站点根目录,访问时直接跳到了目录列表,或者首页能打开但其他页面全部 404。原因就是没有把站点根目录指向public,也没有配伪静态。
以 Nginx 为例,站点配置的root要指向项目的public目录:
server { listen 80; server_name your-domain.com; root /var/www/tp6/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } } location ~ \.php($|/) { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }这里的核心是rewrite那行:当请求的路径在文件系统里不存在时,把请求交给index.php处理,框架再根据s参数解析路由。如果你用的是 Apache,对应的伪静态规则是:
<IfModule mod_rewrite.c> Options +FollowSymlinks -Multiviews RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php?s=/$1 [QSA,PT,L] </IfModule>这段规则要放到public/.htaccess文件里。很多人在本地用 PHP 内置服务器开发,完全不需要这些伪静态配置,但一上服务器就各种 404,基本都是漏了这一步。
4.3 首次运行:开启调试模式看真实错误
配置完成后,浏览器访问你的域名,如果能看到 ThinkPHP 的默认欢迎页面,说明框架已经跑起来了。如果页面是空白或者 500 错误,那多半是 PHP 报错了但被隐藏了。TP6 默认是关闭调试模式的,错误信息不会直接显示在页面上,而是写进日志文件。我刚入门时不懂这个,白屏就不知道怎么办,后来才会去查日志。
开启调试模式的方法是修改项目根目录下的.env文件:
APP_DEBUG=true APP_TRACE=true.env文件在create-project生成的项目里是存在的,但如果你用的是官网源码包,可能没有这个文件,需要手动复制.example.env为.env。开启后刷新页面,浏览器会直接显示异常详细信息,包括错误文件、行号和调用链。排错完成后,别忘了把APP_DEBUG改回false,毕竟生产环境暴露错误堆栈是很危险的事情。我的习惯是本地开发永远开着调试模式,部署到测试环境关一半,到生产环境必须全关。
5. ThinkPHP 6 下载后的 5 个常见坑与排查
5.1 坑一:composer install报错说 PHP 版本不满足
现象:在本地执行composer install时,提示类似Your PHP version (7.1.3) does not satisfy that requirement。
原因:Composer 读取的是命令行 PHP 版本,而不是浏览器访问的那个。有时候你安装了多个 PHP 版本,命令行默认指向了旧版本。
解决:where php(Windows)或which php(Linux)确认实际调用的 PHP 路径。如果指向了旧版本,要么修改环境变量,要么在 Composer 命令前手动指定,比如/usr/bin/php8.1 composer install。改完以后再执行php -v确认版本已经切换,这个操作需要在新开的终端窗口里才会生效。
5.2 坑二:项目下载好了但访问首页出现一堆警告
现象:首页能打开,但页面顶部出现黄色的Deprecated警告或者Warning级别的错误。
原因:PHP 版本高于框架预期,某些旧的写法在更高的 PHP 版本里被标记为弃用。这个在 PHP 8.0 以上跑 TP6.0 时比较常见。
解决:在.env文件里设置APP_DEBUG=false,生产环境本来就不该显示警告。如果还想看到警告信息做兼容性调整,可以在public/index.php入口文件顶部临时加入error_reporting(E_ALL & ~E_DEPRECATED);来屏蔽弃用类报错。但这不是长久之计,最好还是升级框架到 6.1 系列,或者针对报错提示的代码做兼容修改。
5.3 坑三:伪静态配了,但模块访问还是 404
现象:首页访问正常,但访问/index/user/list这种多级路径返回 404,或者直接找不到页面。
原因:TP6 的路由模式和伪静态规则不匹配。TP6 默认使用混合路由模式,路径里的index是应用名,user是控制器,list是方法。伪静态规则只重写了一次,没有正确传递完整的路径参数。
解决:先确认访问index.php?s=/index/user/list是否能正常访问,如果能,说明确实是伪静态问题。检查 Nginx 配置里的 rewrite 规则是否把$request_filename判断写对了,文件路径不存在的条件漏了就会跳过重写。还有一种是 Nginx 配置里有多个location段互相干扰,我建议把location /里的 rewrite 配置移到server层级试试,避开 location 匹配的优先级问题。
5.4 坑四:连接数据库报could not find driver
现象:安装没问题,但一操作数据库就报PDOException: could not find driver。
原因:PHP 装了 PDO 扩展,但没装具体的数据库驱动。比如连 MySQL 需要pdo_mysql扩展,只装pdo是不够的。
解决:执行php -m | grep pdo查看已装的 PDO 相关扩展。如果没有pdo_mysql,在 Windows 上去掉php.ini里extension=pdo_mysql前的分号注释,然后重启服务;在 Ubuntu 上执行sudo apt install php-mysql,在 CentOS 上执行sudo yum install php-mysqlnd。装完后再次确认,扩展加载成功是跑数据库的前提。
5.5 坑五:静态文件全部 404,样式和图片都不显示
现象:页面 HTML 能正常输出,但 CSS、JS、图片全部访问不了,浏览器控制台一片红。
原因:项目配置了强制 HTTPS 或者域名根路径不对,静态资源路径用的是绝对路径,但在当前环境下解析不到。还有一种情况是安装的时候用的是站点根目录,而不是public目录,导致静态资源路径全部错位。
解决:如果用的 Nginx 站点配置,检查root是否指向了public目录,确保location ~ \.php里SCRIPT_FILENAME也能正确拼接出文件路径。另外在 TP6 的模板视图里,优先使用url()工具函数生成资源路径,别手写相对路径。手写路径一旦调整目录层级就会翻车,这是我见过的最容易出现的问题,没有之一。
6. 最后一步:让下载完的框架跑出第一个页面的两个验证技巧
6.1 用内置命令快速启动开发服务器
框架跑通以后,你不需要每次都配置 Nginx 或 Apache 来做开发调试。TP6 自带了 PHP 内置服务器启动命令:
php think run默认监听8000端口,浏览器访问http://localhost:8000。如果想改端口和绑定地址:
php think run -H 0.0.0.0 -p 8080-H指定监听地址,0.0.0.0表示允许外部机器访问,-p指定端口。这个命令特别适合本地写接口联调的时候,不用开完整的 Web 服务器,启动快,日志输出也直观。我在某公司做过一个模拟项目X的接口服务,全流程就是靠php think run做单测联调的。
6.2 用日志验证框架核心链路完整
如果默认欢迎页出不来,除了开调试模式,还可以直接看运行时日志。TP6 的日志默认写在runtime/log/目录,按日期生成文件。查看某个时间段的日志:
tail -f runtime/log/202501.log日志会记录包括路由解析、SQL 执行、异常堆栈在内的所有关键信息。有一次我在帮某跨平台系统排查问题时,页面白屏但日志里什么都有,最后发现是模板缓存目录没有写权限。runtime目录在 Linux 下必须给 Web 用户写权限:
chmod -R 775 runtime chown -R www-data:www-data runtime这个权限问题是黑匣子级别的坑,PHP 不报错,但功能就是不对。我的习惯是每次新环境部署完,强制看一眼日志目录有没有写入内容,没有内容说明权限或路径有问题,早发现早处理。希望这个排查习惯能帮到你,祝少踩坑。
本文还有配套的精品资源,点击获取