Composer dump-autoload 变慢是因为默认启用--optimize，全量重写autoload_classmap.php；开发时应禁用优化：用--no-optimize或设"optimize-autoloader": false，而非--classmap-authoritative。
为什么 composer dump-autoload 会变慢？
因为 Composer 默认开启自动加载优化（--optimize），它把所有 PSR-4/PSR-0 类映射合并成一个大数组，生成 vendor/composer/autoload_classmap.php。开发时类频繁增删，这个文件每次都要全量重写+重排序，IO 和 CPU 开销明显。
禁用优化的正确方式：加 --classmap-authoritative 吗？
不加。那个选项是反向操作——它让 Composer 完全忽略 PSR 映射，只信 classmap，反而更慢、更僵硬。真正要关的是优化本身：
- 开发阶段执行
composer dump-autoload --no-optimize，跳过 classmap 生成 - 或者在
composer.json里设"optimize-autoloader": false，一劳永逸 - 注意：
--no-optimize不影响 PSR-4 自动发现，只是不合并；类仍能正常加载，只是少了一层缓存
autoload-dev 里的类会被优化吗？
会，只要在 autoload 或 autoload-dev 块中声明了路径，就统一参与 classmap 构建。但实际开发中，测试类（如 tests/）通常只在 autoload-dev，你又不希望它们拖慢主流程——所以建议：
- 把
tests/移出autoload-dev的 PSR-4 声明，改用files方式按需加载 - 或干脆不声明 autoload-dev，靠 PHPUnit 的
--bootstrap手动引入 - 否则每次
dump-autoload都会扫描整个tests/目录，尤其含大量 mock 类时特别卡
CI/CD 和本地开发必须用同一套配置吗？
不必。Composer 允许环境区分：
- 本地开发：设
"optimize-autoloader": false+"classmap-authoritative": false - 生产部署：用
composer install --no-dev --optimize-autoloader --classmap-authoritative - 关键点：
--classmap-authoritative只在生产有意义，它跳过文件存在性检查，提速明显，但开发时会导致“类已删却还被加载”的诡异问题
最常被忽略的是：很多人只关了 --optimize-autoloader，却忘了 CI 脚本里没加 --no-dev，结果把 autoload-dev 里的路径也塞进 classmap，白忙一场。
