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 下的类必须有正确命名空间（如 app\controller\IndexController），否则反射失败——这在 TP6 里可能只是警告，TP8 下直接报 Class not found。
常见错误现象：ReflectionException: Class app\controller\IndexController 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/ 这种硬编码路径引用
• 所有核心类（如 think\App、think\Db）必须通过 Composer 自动加载，不能手动 require
• 若你在 TP6 里习惯修改 thinkphp/library/think/Route.php 来打补丁，TP8 下这条路彻底堵死，必须走服务提供者或事件监听扩展
性能影响：启动时类加载更快（OPcache 友好），但调试时找不到源码位置是新手最常卡住的点——记得用 IDE 的 “Go to Definition” 跳转到 vendor/ 对应包内
PHP 8.5.12 RC 1 候选版修复 BZ2、DOM、PDO、Opcache/JIT 和扩展内存安全问题，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
public 目录权限与上传风险没变，但防御逻辑更依赖配置项
TP6 和 TP8 都要求只有 public/ 可对外访问，这点没变；但文件上传校验机制变了：
TP6 默认用 think\File 类做基础验证，开发者常自己加后缀白名单；TP8 则强制走 think\filesystem\Driver 抽象层，上传前必须配置 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 操作的实际落盘位置。
