默认情况下optimize-autoloader为false，启用后会生成并加载autoload_classmap.php以加速类加载；可通过检查vendor/autoload.php、composer.json或运行composer config optimize-autoloader确认状态；调试时应禁用以暴露真实加载问题。
默认情况下，optimize-autoloader 是 false，但只要运行过 composer install 或 composer update 且没显式禁用，它就可能被设为 true——尤其在 CI 或生产环境脚本里悄悄启用。
怎么确认当前是否启用了 autoloader 优化
看 vendor/autoload.php 开头几行：如果生成的文件里有 ClassLoader::setOptimized(true) 或包含大量预生成的类映射数组（如 $map = [ 'Foo\Bar' => __DIR__ . '/..' . '/src/Bar.php' ]），说明已启用优化。也可以直接检查 composer.json 中是否有 "optimize-autoloader": true 字段，或运行：
composer config optimize-autoloader
返回 true 表示全局配置已开启；若报错或无输出，则未显式设置（即默认 false）。
如何强制关闭 optimize-autoloader（本地调试时）
调试阶段需要看到类加载的真实路径和顺序，比如排查 Class not found 是因为命名空间写错、还是 PSR-4 映射漏配，这时必须关掉优化——它会跳过动态查找，直接查静态映射表，掩盖问题。
- 临时关闭：加
--no-optimize-autoloader参数，例如composer install --no-optimize-autoloader - 永久关闭（项目级）：在
composer.json中写死"optimize-autoloader": false，然后执行composer dump-autoload - 全局关闭（不推荐）：用
composer config -g optimize-autoloader false，会影响所有项目，容易误伤
为什么关掉后 autoload_classmap.php 还在？
这是常见误解：optimize-autoloader 控制的是「是否生成并使用 vendor/composer/autoload_classmap.php」，但该文件本身是 dump-autoload 的副产品，不一定被加载。关键看 vendor/autoload.php 是否调用了它。
- 当
optimize-autoloader=true时，autoload.php会 requireautoload_classmap.php并启用映射查找 - 当
optimize-autoloader=false时，即使文件存在，也不会被载入；类加载退回到逐个扫描psr-4和psr-0配置的目录 - 删掉
autoload_classmap.php不影响功能，但下次运行带--optimize-autoloader的命令会重建它
CI/CD 里关掉它，会不会拖慢测试速度？
会，但只在首次加载类时明显。对 PHPUnit 单测来说，多数类只加载一次，影响有限；而开发中频繁修改代码、触发自动重载时，关掉反而更准——比如改了类名但忘了更新 composer.json 的 psr-4，优化模式下旧映射还在，测试可能“侥幸”通过。
- CI 环境建议：开发分支关掉，release 分支再打开（用
--optimize-autoloader） - 别在
composer.lock提交里混用不同优化状态，会导致本地和 CI 加载行为不一致 - PHP 8.1+ 下，若用了
opcache.preload，还要注意 preload 脚本是否依赖优化后的映射——关掉optimize-autoloader后，preload 可能失败
最常被忽略的一点：某些 IDE（比如 PHPStorm）的代码跳转依赖 autoload_classmap.php，关掉优化后，它可能找不到类定义——这不是 Composer 的问题，而是 IDE 缓存没刷新，手动触发 File > Reload project from Disk 就行。
