autoload_real.php 通过 getLoader()->register(true) 调用 spl_autoload_register([$loader, 'loadClass']) 注册统一加载器；loadClass() 先查 classmap（O(1)），未命中则遍历 autoload_psr4.php 中的命名空间前缀映射（键为带双反斜杠结尾的前缀，值为绝对路径数组），按 PSR-4 规则拼路径（→目录分隔符、去前缀、加 .php）、file_exists() 校验后 require；files 则在 autoload.php 引入时立即 require_once，用于预加载函数/常量等。
autoload_real.php 是怎么把 PSR-4 映射注册进 spl_autoload_register 的
它不直接注册 PSR-4 逻辑，而是注册一个统一的 loadClass() 方法。这个方法在运行时才根据已加载的映射表（autoload_psr4.php、autoload_classmap.php 等）决定怎么找文件。
关键点在于：autoload_real.php 在 getLoader() 中调用 $loader->register(true)，这行代码最终触发 spl_autoload_register([$loader, 'loadClass'])。所有后续类加载请求都走这个 loadClass()。
-
loadClass()先查classmap（O(1) 查表，最快） - 没命中再按 PSR-4 规则遍历
autoload_psr4.php中的前缀列表，尝试拼路径 - PSR-4 拼路径时会把命名空间反斜杠
替换为目录分隔符，并去掉前缀后匹配子路径 - 最后用
file_exists()判断文件是否存在，存在才require
autoload_psr4.php 里存的是什么结构
它是一个 PHP 数组，键是命名空间前缀（带结尾反斜杠），值是对应根目录的绝对路径数组（支持多个路径）：
return array(
'App\' => array($vendorDir . '/myproject/src'),
'Tests\' => array($baseDir . '/tests')
);
注意两点：
- 每个前缀可能对应多个路径（比如开发时想同时加载 src/ 和 stubs/ 下的类）
- Composer 生成时会自动把相对路径转成绝对路径（
$baseDir、$vendorDir是预定义常量） - 如果写错前缀末尾没加
\（比如写成"App"），PSR-4 匹配会失败，类永远加载不到
为什么 classmap 比 PSR-4 快，但开发期很少手动用
classmap 是纯数组查表：类名作为 key，文件路径作为 value，isset($map[$class]) 就能立刻返回结果，没有路径拼接和 file_exists() 开销。
但它需要扫描文件生成，所以有三个硬约束：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 一旦类文件增删，必须重新运行
composer dump-autoload --optimize同步映射 - 无法支持动态命名空间（比如运行时拼接类名再实例化），因为映射是静态的
- 修改类名或移动文件后，旧映射残留会导致加载错误类，静默出错风险高
因此生产环境开 "optimize-autoloader": true 是安全的，但开发中改代码频繁时，PSR-4 的“所见即所得”更可靠。
files 自动加载项为什么总被忽略却很关键
"files" 字段在 composer.json 中声明的 PHP 文件，会在 autoload.php 被引入时**立即执行 require_once**，不等类被使用。
典型用途：
- 全局函数定义文件（如
src/functions.php） - 常量定义或环境配置（
config/constants.php） - 需要提前挂载的 Traits 或接口别名
容易踩的坑：
- 文件里不能有重复定义（比如两次
define()或function_exists()检查缺失） - 路径写相对路径时，
composer dump-autoload会把它转成绝对路径，但若该文件被移动，不会自动更新 - 它不参与任何命名空间解析，纯粹靠路径硬加载——放错位置就报
Cannot redeclare function
真正难调试的是：它加载时机早于所有 PSR-4 类，但又不报错，只在函数冲突或常量重复时才暴露问题。
