启用 -o 选项能显著提升自动加载速度，因其生成 classmap 避免运行时路径探测；但仅对 classmap 显式声明或非 PSR-4/PSR-0 覆盖的文件生效，不扫描 PSR-4 目录下所有 PHP 文件。
生产环境的 composer install 后自动加载慢，本质是 autoload.php 加载了太多动态查找逻辑。启用 -o（即 --optimize-autoloader）能显著提速，但它不是万能开关，得看项目结构和类声明方式。
为什么 -o 能加快自动加载
默认情况下，Composer 使用 PSR-4/PSR-0 映射，每次 new FooBar() 都要按命名空间规则拼路径、检查文件是否存在——IO 开销大。-o 会生成一个完整的 classmap，把所有类名到文件路径的映射提前固化进 vendor/composer/autoload_classmap.php，运行时直接查表，跳过文件系统探测。
注意：它只对满足以下任一条件的文件生效：
- 在
"autoload": {"classmap": [...]}中显式声明的目录或文件 - 不在 PSR-4/PSR-0 规则覆盖范围内，但被
composer dump-autoload -o扫描到的 PHP 文件（如src/functions.php这类全局函数文件）
-o 不会扫描 PSR-4 目录下的所有 PHP 文件
这是最常被误解的一点。即使你写了 "autoload": {"psr-4": {"App\": "src/"}}，加了 -o 也不会把 src/ 下所有 .php 文件都塞进 classmap——它只把 PSR-4 映射本身写进优化后的 loader，类文件仍靠动态路径拼接加载。
真正进 classmap 的，是那些「没走 PSR 规则」的文件，比如：
-
src/helpers.php（非类文件，但被autoload.files引入） -
lib/legacy/SomeOldClass.php（放在"classmap": ["lib/legacy/"]里） -
vendor/some/package/stubs.php（某些包自带的桩文件，未遵循 PSR）
所以如果你的 src/ 下混着大量非标准命名的类（比如 MyUtil_v2.php），它们不会被 -o 自动收录，得手动加进 classmap。
生产部署时该用 composer install -o --no-dev 还是 dump-autoload -o
两者效果一致，但触发时机和可控性不同：
-
composer install -o --no-dev：适合 CI/CD 流水线一键构建，自动跳过 dev 依赖 + 生成优化 autoload。但前提是composer.lock已提交且稳定。 -
composer dump-autoload -o --no-dev：适合已部署好 vendor 的环境（如容器内），只需重生成 autoload，不重装包。更轻量，也避免因网络或权限问题卡在 install 阶段。
额外提醒：--no-dev 不影响 -o 的 classmap 构建逻辑，但它会让 Composer 忽略 require-dev 中的包——这些包里的类自然也不会出现在最终的 classmap 中，这点必须和测试环境对齐，否则本地能跑、线上报 Class not found。
classmap 优化的隐藏代价：构建时间与缓存失效
-o 会让 composer install 或 dump-autoload 变慢，因为它要递归扫描所有 classmap 目录下的 PHP 文件、解析 class/interface/trait 声明。一个含 5000+ PHP 文件的 lib/ 目录，可能多耗 10–20 秒。
更关键的是：只要 classmap 目录下任意 PHP 文件内容变更（哪怕只是改个注释），下次 dump-autoload -o 就会重新全量扫描——无法增量更新。而 PSR-4 映射本身是静态配置，不受文件内容影响。
所以别盲目把整个 src/ 加进 classmap，除非你确认这些类极少变动，且运行时性能瓶颈确实在 autoload 查找上（可用 xdebug 或 blackfire 验证）。
