真正起效的是 composer install --optimize-autoloader，它强制重建 autoload_classmap.php；而 dump-autoload -o 在 composer 2.x 中默认不生成 classmap 文件，除非显式配置 classmap 或使用 --classmap-authoritative。
别用 composer dump-autoload -o 优化性能，它在 PHP 7.4+ 和 Composer 2.x 中基本无效，甚至让冷启动更慢；真正起效的是 composer install --optimize-autoloader（或简写为 composer install -o）。
为什么 composer dump-autoload -o 不生成 autoload_classmap.php
这个命令默认不重建 classmap 文件，只刷新 autoload_static.php 和 PSR-4 映射表。即使加了 -o，只要项目没显式配置 "classmap" 字段，Composer 2.x 就跳过扫描——vendor/composer/autoload_classmap.php 要么不存在，要么为空。
- 执行后立刻检查该文件：大小为 0 或根本不存在 → 说明没生效
- 它不会重新扫描
autoload块里的 PSR-4 路径，除非你同时加了--classmap-authoritative或项目里真有"classmap": ["src/"]这类配置 - 很多项目误以为“加了 -o 就快了”，结果 strace 显示
stat()调用没减少，内存占用反而翻倍
真正重建 classmap 的命令是 composer install --optimize-autoloader
这条命令强制 Composer 重新解析所有 autoload 配置（PSR-4、files、classmap），并生成精简、准确的 autoload_classmap.php。它才是 CI/CD 部署中必须写死的操作。
- 必须搭配
--no-dev：否则autoload-dev里的路径（如"tests/": ["tests/"]）也会被扫进 classmap，徒增体积 - 它会跳过 vendor 缓存逻辑，确保映射与当前代码严格一致
- 验证是否生效：打开
vendor/composer/autoload_real.php，搜索addClassMap—— 如果这行被调用，说明 classmap 已加载
--classmap-authoritative 不是提速开关，而是断电式加载
它让自动加载器彻底放弃 fallback：查不到 classmap 就直接报 Class not found，不拼路径、不 file_exists()、不遍历目录。但它只在条件严苛时才安全。
- 必须满足：所有类名与路径严格符合 PSR-4（比如
namespace AppConsoleCommands;对应app/Console/Commands/DeployCommand.php，末尾反斜杠不能少） - 不能有
"files"类型加载的全局函数文件依赖 fallback（虽然它们本身不受影响，但容易误判问题根源） - 本地开发禁用：开了之后
php artisan tinker、PHPUnit 临时类、IDE 补全都可能崩
性能瓶颈往往藏在 composer.json 配置里
比纠结要不要加参数更重要的，是清理 autoload 配置本身。一个臃肿的 classmap 比不优化还糟。
- 删掉无用条目：
"docs/": ["docs/"]、"examples/": ["examples/"]这类会让扫描白跑几百个文件 - 避免过宽前缀：
""（空字符串）匹配整个目录，改成"App\": "app/"才精准 - 确认没有重复注册：比如
"App\": "app/"同时出现在psr-4和classmap中，会叠加处理，增加匹配耗时 - OPcache 必须配
opcache.revalidate_freq=0，否则每次请求都检查autoload_classmap.php时间戳，classmap 优化白费
真正关键的不是“怎么加参数”，而是“谁该进 classmap”和“谁不该被扫描”。生成一个几 MB 的全量数组，不如删掉三个无用的 autoload 条目来得实在。
