tp8目录结构看似与tp6一致,但底层全面升级为psr-4自动加载、容器绑定及composer化框架;多应用模式配置逻辑重构,需显式启用app_multi并为子应用配置独立config/route目录;thinkphp目录消失,上传校验强制依赖Filesystem.deny_ext。

单应用模式下目录结构基本没变,但“隐性规则”全升级了
从 public 入口、app(TP6)或 application(TP8 默认仍兼容该名,但推荐用 app)、config、route 这些主干路径看,TP6 和 TP8 的单应用目录骨架几乎一致。但关键差异藏在“谁来管”和“怎么加载”里:
TP6 的 app 目录默认就是应用根,所有控制器、模型、视图都往里塞;TP8 虽然也沿用类似结构,但底层已切换为基于 PSR-4 自动加载 + 容器绑定的现代方式,app/controller 下的类必须有正确命名空间(如 appcontrollerIndexController),否则反射失败——这在 TP6 里可能只是警告,TP8 下直接报 class not found。
常见错误现象:ReflectionException: Class appcontrollerIndexController does not exist,往往不是路径错了,而是命名空间漏写或大小写不匹配(linux 环境尤其敏感)。
多应用模式配置逻辑彻底重构,不能再照搬 TP6 写法
TP6 多应用靠在 app 目录下建子目录(如 app/admin、app/api),再配合 app/multi.php 或路由分组启用;TP8 已移除对 multi.php 的原生支持,改由 app/middleware.php 和路由分组 + 应用中间件联合控制,且要求每个子应用必须有独立的 config/ 和 route/ 子目录(如 app/admin/config/app.php)。
实操建议:
• 删除 TP6 遗留的 app/multi.php 文件,它在 TP8 中完全无效
• 每个子应用目录下必须包含 config/ 和 route/,哪怕只放一个空 app.php
• 启用多应用需在全局 config/app.php 中显式设置 'app_multi' => true,否则即使目录存在也不会识别
• 若沿用 TP6 的“伪多应用”(仅靠路由前缀区分),TP8 仍能跑,但无法享受应用级配置隔离优势
核心目录语义变化:thinkphp 目录消失,框架层彻底 Composer 化
TP6 项目里能看到 thinkphp/ 目录(含 library、lang 等),这是框架源码直连;TP8 中这个目录**不再生成**——整个框架被拆成多个 Composer 包(topthink/framework、topthink/think-orm、topthink/think-filesystem),全部放在 vendor/ 下。这意味着:
• 不再有 thinkphp/library/think/ 这种硬编码路径引用
• 所有核心类(如 thinkApp、thinkDb)必须通过 Composer 自动加载,不能手动 require
• 若你在 TP6 里习惯修改 thinkphp/library/think/Route.php 来打补丁,TP8 下这条路彻底堵死,必须走服务提供者或事件监听扩展
性能影响:启动时类加载更快(OPcache 友好),但调试时找不到源码位置是新手最常卡住的点——记得用 ide 的 “Go to Definition” 跳转到 vendor/ 对应包内
public 目录权限与上传风险没变,但防御逻辑更依赖配置项
TP6 和 TP8 都要求只有 public/ 可对外访问,这点没变;但文件上传校验机制变了:
TP6 默认用 thinkFile 类做基础验证,开发者常自己加后缀白名单;TP8 则强制走 thinkfilesystemDriver 抽象层,上传前必须配置 filesystem.default 并启用 deny_ext 规则(如 ['php', 'phtml', 'exe']),否则即使前端限制了类型,攻击者仍可通过 .jpg.php 绕过。
容易踩的坑:
• 升级后忘记在 config/filesystem.php 中配置 'deny_ext',导致上传漏洞重现
• 使用第三方存储(如阿里云 OSS)时,TP8 的 think-filesystem v2.0 不再自动继承 TP6 的 root 路径逻辑,需显式设置 'url' 和 'visibility'
• public/Static/ 这类静态资源目录,在 TP8 中不再被框架自动管理,要靠 nginx/apache 显式配置禁止执行 PHP
立即学习“PHP免费学习笔记(深入)”;
最易被忽略的是:TP8 的目录结构“看起来一样”,但每个路径背后加载时机、作用域和安全边界都重写了。别信“能跑就行”,得逐个验证配置加载顺序、类自动注册行为、以及上传/缓存/日志等 IO 操作的实际落盘位置。