Composer 不实现按需加载，仅生成静态映射；真正的按需由 PHP 运行时触发，优化重点是映射精准、查找快速、初始化轻量；PSR-4 是唯一真正延迟加载机制，依赖命名空间前缀与类名拼接路径，但须严格满足配置格式、目录结构及前缀优先级规则；classmap 反而可能成为冷启动瓶颈，尤其误用 --optimize-autoloader 或包含无关路径时；--classmap-authoritative 仅适用于生产环境且要求 classmap 覆盖全部类；镜像源仅加速包下载，不影响 autoload 逻辑。
Composer 本身不实现按需加载，它只生成静态映射；真正的“按需”由 PHP 运行时触发——new、class_exists()（非 autoload = false 模式）、static::class 等操作才会查映射、加载文件。优化重点不是让 Composer 更懒，而是让映射更准、查找更快、初始化更轻。
PSR-4 是唯一真正延迟加载的机制
它不扫描目录、不生成 classmap，靠命名空间前缀 + 类名字符串拼接路径，例如 AppHttpControllersHomeController → src/Http/Controllers/HomeController.php。但必须满足硬性条件：
-
composer.json中 PSR-4 映射末尾必须带反斜杠："App\": "src/"，写成"App": "src/"或"App\": "src"（缺末尾斜杠）都会失效 - 目录结构必须严格对齐：若配置
"App\": "src/"，则类AppConsoleCommandDeployCommand必须落在src/Console/Command/DeployCommand.php，不能多一层src/App/ - 多个 PSR-4 前缀重叠时（如
"App\Console\": "app/Console/"和"App\": "app/"），更具体的前缀必须写在更宽泛的前面，否则匹配被提前截断
classmap 不等于快，反而可能是冷启动瓶颈
很多人误以为加了 --optimize-autoloader 就一定快，实际它会生成全量 autoload_classmap.php，体积常达 2–5 MB（尤其当 composer.json 错误包含 "tests/": ["tests/"] 或未加 --no-dev）。单次请求只用到其中不到 5% 的类，却要反序列化整个数组。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer dump-autoload -o默认不重建 classmap，只刷新 PSR-4 映射表；真正生成 classmap 只发生在install或update阶段 - 验证是否真生效：检查
vendor/composer/autoload_classmap.php是否存在且含数千行；搜索vendor/composer/autoload_real.php中是否有addClassMap调用 - 启用
--classmap-authoritative后，任何未被 classmap 覆盖的类（包括你自己的新类）将直接报Class 'XXX' not found，所以仅建议在生产环境启用
镜像源不影响 autoload 逻辑，只加速下载
阿里云、腾讯云等镜像源只影响 composer install 或 update 时的包下载速度与稳定性，不参与 autoload 文件生成。类映射逻辑完全由本地 composer.json 配置 + 执行命令 + 环境变量决定。
- 换镜像后 install 变快 ≠ autoload 变快；只是下载快，autoload 还是默认 PSR-4 查找
-
COMPOSER_MIRROR环境变量无效，正确方式是composer config -g repo.packagist https://mirrors.aliyun.com/composer/ - 镜像同步延迟可能导致
vendor/中某些包版本旧，类名或命名空间变动未被 classmap 扫到，开了--classmap-authoritative直接报错
最易被忽略的点：autoload 性能卡点往往不在命令本身，而在 composer.json 里写了不该扫的路径（如 docs/、examples/）、用了 files 加载却忘了它不进 classmap、或者部署时漏掉了 --no-dev —— 这会让开发依赖里的测试类污染 classmap，体积暴涨且毫无意义。
