部署时需跳过 composer install --optimize-autoloader，因其生成 classmap 和优化 psr-4 映射会显著拖慢速度；应使用 --no-dev --no-scripts --no-autoloader-optimize 组合确保生效。
部署时为什么需要跳过 composer install --optimize-autoloader
因为自动加载优化（生成 vendor/autoload_classmap.php 和优化 PSR-4 映射）会显著拖慢部署速度，尤其在 vendor 包多、类文件海量的项目里。CI/CD 流水线或容器镜像构建阶段，你往往只需要确保依赖可加载，不追求运行时那几毫秒的 autoload 性能提升——这时候跳过它，能省下几秒到几十秒。
--no-autoloader-optimize 的真实作用和常见误用
这个 flag 并不是“禁用所有 autoload 优化”，它只跳过两件事：生成 classmap 和 合并 PSR-4/PSR-0 映射为静态数组。autoload 本身依然工作（靠 require + 文件扫描），只是没做预计算。
- 它不会影响
composer dump-autoload的其他行为（比如生成autoload_static.php） - 它不能替代
--no-scripts或--no-plugins：如果你的post-install-cmd脚本内部又手动调了dump-autoload --optimize，这个 flag 就白加了 - 它对
composer update无效——只有install和update的子命令dump-autoload才认这个参数
真正生效的部署命令组合
单靠 --no-autoloader-optimize 很容易被环境或配置覆盖。要稳住效果，得配合几个关键开关：
- 显式加上
--no-dev：避免 dev 依赖带来的额外 classmap 条目干扰 - 必须加
--no-scripts：防止post-install-cmd里藏着composer dump-autoload --optimize - 确认
composer.json没开"optimize-autoloader": true—— 这个配置会覆盖命令行 flag - 推荐完整命令：
composer install --no-dev --no-scripts --no-autoloader-optimize
跳过后要注意的运行时表现
跳过优化后，首次请求可能稍慢（PHP 需动态解析 PSR-4 前缀），但后续 APCu / OPcache 缓存生效后几乎无感。真正要小心的是两类场景：
- 某些老版本 Laravel（vendor/autoload_classmap.php 是否存在，找不到就报错——这时得补一个空 classmap 或升级框架
- 如果项目用了
classmap类型的 autoloading（比如 legacy 目录），跳过优化会导致这些类无法被自动加载，必须保留--classmap-authoritative或改用psr-4 - 容器部署时，若 base image 已预生成 autoload，而你又在运行时执行
composer install --no-autoloader-optimize，可能造成 autoload 状态不一致
autoload 优化不是非黑即白的开关，它是权衡：部署快 vs 启动略慢 vs 兼容性边界。别只盯着 flag，得看你的框架、PHP 版本、缓存策略怎么配合。
