composer dump-autoload 变慢主因是大量 PSR-0/PSR-4 扫描与 classmap 合并导致 I/O 和解析开销上升；优化建议包括禁用冗余映射、清理 autoload.files、避免误配路径，并在 CI 中使用 -o --classmap-authoritative，开发时慎用。
为什么 composer dump-autoload 会变慢？
当项目依赖多、类文件数量大（尤其含大量 PSR-0/PSR-4 映射或自定义 autoload 配置），composer dump-autoload 会遍历所有匹配路径扫描 .php 文件，生成 vendor/autoload_*.php。默认启用 --optimize（即 -o）时还会做类映射（classmap）合并，I/O 和解析开销明显上升。
常见症状：dump-autoload 耗时从几百毫秒涨到数秒；CI 流水线中频繁触发导致构建延迟；本地开发改一个 autoload 配置后等太久。
- 避免在
composer.json中混用psr-0和psr-4映射同一命名空间——Composer 会重复扫描 - 移除已废弃的
autoload.files中冗余脚本（如调试用的临时include） - 确认没有把
vendor/或node_modules/等非 PHP 目录意外写进psr-4的路径值里
何时该用 --classmap-authoritative？
这个选项让 Composer 在运行时跳过文件存在性检查，直接查 classmap —— 能显著提升 autoloader 加载速度，但要求 classmap 必须完整覆盖所有类，否则抛出 Class not found 错误。
它只在执行 dump-autoload -o 时生效，且会写入 vendor/composer/autoload_classmap.php。适合部署环境或 CI 构建后锁定类结构的场景。
- CI 中建议组合使用：
composer dump-autoload -o --classmap-authoritative - 开发阶段慎用：新增类但忘记重新 dump，会导致运行时报错且不易定位
- 搭配
"optimize-autoloader": true到composer.json的config段可全局启用优化（但仍需手动 dump 才生效）
composer dump-autoload 的轻量替代方案
并非每次修改都要全量重生成 autoload 文件。比如只改了某个 PSR-4 命名空间路径，或只增删了几个类，可以用更精准的方式绕过全量扫描。
- 加
--no-scripts防止触发 post-autoload-dump 脚本（尤其当这些脚本本身又调用了 Composer 命令时容易死循环） - 用
--no-dev在生产构建中跳过autoload-dev部分，减少 classmap 大小 - 若只是临时测试，可直接编辑
vendor/autoload.php引入自己的 loader（不推荐长期用，但调试 autoload 逻辑时很直观）
自定义 autoloader 时如何避开 dump-autoload？
如果你在 composer.json 里写了 "autoload": { "files": ["src/helpers.php"] }，那每次改 helpers.php 都不需要 dump-autoload —— 因为它是硬编码 require 的。但要注意：
-
files列表里的文件会在每次请求时无条件加载，影响启动性能，别塞大文件或含 heavy init 逻辑的脚本 - 如果该文件内部又 require 其他动态路径文件（如
__DIR__ . '/configs/' . ENV . '.php'），Composer 不会追踪这些间接依赖，dump-autoload对它们完全无效 - 想让 IDE 正确识别
files中函数，得额外配intelephense.environment.includePaths或用@var注解，否则跳转和补全会断
真正难搞的是嵌套在第三方包里的 autoload 配置变更，或者 classmap 生成后被 Git 忽略却未同步到部署机——这类问题不会报错，但类就悄悄消失了。
