ThinkPHP 6+自动加载完全依赖Composer的PSR-4机制，根本原因在于框架已移除自身加载逻辑，将控制权完全交予Composer；必须确保命名空间、物理路径、文件名大小写严格一致，并执行composer dump-autoload -o生效。
ThinkPHP必须遵循PSR-4自动加载规范，根本原因不是框架强制要求，而是从ThinkPHP 6.0起，自动加载机制已完全移交Composer管理——框架自身不再维护独立的类加载逻辑。这意味着PSR-4不是“推荐做法”，而是实际生效的唯一路径。
PSR-4是命名空间与文件路径之间的确定性映射规则
它把AppHttpControllersUserController这样的完整类名，机械地拆解为：
- 前缀
App→ 对应目录app/（由composer.json配置） - 剩余部分
HttpControllersUserController→ 拼成子路径Http/Controllers/UserController.php
整个过程不依赖猜测、不依赖配置项开关，只要三者对齐：命名空间声明、物理路径、文件名，就能100%定位到文件。
不遵循PSR-4，自动加载链就断在第一步
常见失效场景直指规范缺失：
-
namespace appcontroller;写成namespace AppController;→ Composer按AppController去app/Controller/找，但实际路径是app/controller/，大小写错即失败（尤其Linux/macOS） - 类文件叫
user.php，类名却是class User→ PSR-4要求文件名必须与类名完全一致，包括首字母大写 -
composer.json里写"App": "app"（漏斜杠）或"App\": "app/"（反斜杠转义错误）→ 映射规则解析失败，Composer直接忽略该条目 - 新增类后没运行
composer dump-autoload -o→ 映射表未更新，Composer仍按旧路径查找
第三方包和自定义类统一纳入同一加载体系
无论是overtrue/pinyin还是你自己写的apputilsArrHelper，只要它们的composer.json或你的项目配置符合PSR-4，就能共用同一套加载器。不需要为每个包单独写require，也不用在框架里反复调用Loader::addPsr4()——这些运行时注册方式在TP6+中已被弃用，强行使用反而会干扰Composer主链。
避免隐性冲突与环境差异
ThinkPHP启动时会注册自己的Loader，但它默认优先级高于Composer；如果两者混用（比如一边配了composer.json，一边又调Loader::addNamespace()），可能出现：
- CLI下能加载，Web请求失败
- 开发环境（Windows）正常，上线（Linux）因大小写报错
- 同一类被重复加载，触发
Cannot declare class错误
统一走PSR-4，等于交出控制权给Composer，消除不确定性。
本质上，PSR-4不是ThinkPHP的“规范”，而是Composer生态的通用语言。TP6+选择彻底拥抱它，是为了让类加载这件事回归标准、可预测、可调试——你改一个命名空间，就知道该动哪一行composer.json、哪个目录、哪个文件名，而不是在框架文档和源码间来回翻找加载逻辑。
