composer自动加载依赖autoload配置、vendor/autoload.php和spl_autoload_register()；class not found主因是类名、路径、命名空间未严格对齐，如psr-4映射与实际目录结构不符、大小写不一致、未执行dump-autoload等。
Composer 的自动加载不是魔法，它靠的是 autoload 配置 + 生成的 vendor/autoload.php 文件 + PHP 的 spl_autoload_register() 机制协同工作；跳过手动 include 的前提是类名、文件路径、命名空间三者严格对齐。
为什么 class not found？—— 自动加载失败的典型原因
最常见的错误不是配置写错了，而是“以为对了，其实没对齐”。比如：
-
composer.json里写了"psr-4": {"App\": "src/"}，但实际类定义是namespace AppControllers;，而文件却放在src/Http/Controller.php—— 路径和命名空间不匹配，AppControllersHttpController就永远找不到 - 用了 PSR-4，但类文件名大小写和类名不一致（尤其在 Linux 环境下），
class UserController必须存为UserController.php，写成usercontroller.php就会失败 - 修改了
composer.json后没运行composer dump-autoload，旧的 autoload map 还在缓存里，新规则压根没生效
psr-4 和 classmap 怎么选？
PSR-4 是推荐默认方案，适合常规项目结构；classmap 是兜底手段，用在无法按规范组织代码的老项目或特殊场景：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
psr-4：声明命名空间前缀到目录的映射，加载时动态拼路径，轻量、可扩展，但要求严格遵循约定 -
classmap：扫描指定目录下所有 PHP 文件，把每个class/interface/trait名和其文件路径记进一个大数组，启动时全载入内存 —— 慢一点、占多点内存，但不挑文件位置和命名 - 混合使用没问题：比如主逻辑走
psr-4，第三方工具类或functions.php这种无命名空间的文件，就丢进classmap或files数组里
手动生成 autoload 文件后，PHP 到底执行了什么？
打开 vendor/autoload.php，你会看到它最终调用 require __DIR__ . '/autoload_real.php'；而 autoload_real.php 的核心就是注册几个闭包到 PHP 的自动加载队列中：
spl_autoload_register(function ($class) {
foreach ($loader->prefixesPsr4 as $prefix => $dirs) {
if (0 === strpos($class, $prefix)) {
$relative = substr($class, strlen($prefix));
$file = $dirs[0] . str_replace('\', '/', $relative) . '.php';
if (file_exists($file)) {
require $file;
return;
}
}
}
});
注意两点：
- 它不一次性加载全部类，只在真正用到某个类时才查路径、读文件、
require—— 这就是“懒加载” - 多个 PSR-4 映射时，
$dirs[0]表示取第一个匹配目录，所以顺序很重要；如果两个前缀都能匹配（比如App\和AppControllers\），得确保更具体的前缀排前面
最常被忽略的细节：自动加载器本身不解析 use 语句，也不处理别名（as）；它只响应 new X、X::method()、extends X 这些真实触发类加载的操作。如果你只写了 use AppFoo; 却没用到 Foo，这个文件根本不会被加载 —— 这既是性能优化点，也是调试时容易误判的地方。
