Composer autoload 变慢主因是 vendor/autoload.php 加载时的文件扫描与映射构建，尤其在 PSR-4 与 classmap 混用或开发依赖过多时；应为稳定第三方库配置 classmap、分离 autoload-dev、生产启用 --optimize-autoloader 和 --classmap-authoritative，并杜绝手动 require_once 干扰自动加载。
Composer autoload 为什么越用越慢？
项目依赖增多后，composer autoloader 的性能瓶颈往往不出现在类加载本身，而在于 vendor/autoload.php 加载时的文件扫描与映射构建过程。尤其是使用 psr-4 或 classmap 混合配置、或存在大量未优化的开发依赖时，ClassLoader::findFile() 可能反复遍历目录，甚至触发 file_exists() 多次调用。
关键判断：如果你的 CLI 命令（如 php artisan tinker 或 phpunit）启动耗时明显超过 100ms，且 strace -e trace=openat,stat 显示大量对 vendor/ 下非核心路径的访问，那 autoload 就是瓶颈所在。
如何用 classmap 替代 PSR-4 加速已知稳定类库
PSR-4 动态拼接路径 + 目录遍历适合开发阶段；但对不常变更的第三方库（如 monolog/monolog、symfony/polyfill），提前生成静态映射更高效。Composer 支持在 composer.json 中为特定包强制启用 classmap 自动加载：
- 在
"autoload"下添加"classmap"数组，填入你确认「只读、无命名空间动态变化」的目录，例如：["vendor/monolog/monolog/src"] - 运行
composer dump-autoload --optimize --classmap-authoritative，这会跳过所有 PSR-4 fallback 查找，直接查表 - 注意：启用
--classmap-authoritative后，任何未被 classmap 覆盖的类（包括你自己的新类）将直接报Class not found—— 所以仅建议在生产环境或 CI 中开启
排除 dev-only 依赖的 autoload 扫描
开发时常用的工具类（如 phpunit/phpunit、fakerphp/faker）默认仍会被写入 autoload map，但它们在生产环境完全不会用到，却拖慢了整个加载链。
解决方案是分离 autoload 配置：
- 在
composer.json中，把开发依赖的 autoload 规则移到"autoload-dev"下，而非顶级"autoload" - 部署生产环境时，执行
composer install --no-dev --optimize-autoloader，此时 Composer 不会解析autoload-dev中的任何规则 - 验证效果：对比
vendor/composer/autoload_classmap.php文件大小，生产版应比开发版小 30% 以上
避免 autoload 误伤：vendor 目录外的 require_once
有些老项目会在入口文件（如 index.php）里手动 require_once 'vendor/autoload.php'，再额外 require_once 'lib/Helper.php' —— 这看似无害，实则破坏了 Composer 的 autoload 机制：一旦该 Helper.php 定义了类，而后续代码又通过 new 实例化它，ClassLoader 会再次尝试查找，造成重复加载或冲突。
正确做法只有一条：
- 确保所有类都走 Composer autoload 机制，即：把
lib/加入composer.json的"autoload": {"psr-4": {"App\": "lib/"}} - 删掉所有手动
require_once对 vendor 或自定义类文件的调用 - 若必须保留某段传统代码，至少用
class_exists('Helper')判断后再加载，避免无条件 include
最易被忽略的是测试引导文件（如 tests/bootstrap.php）里残留的 require，它们在 PHPUnit 启动时就会污染 autoload 状态。
