composer install --no-dev --optimize-autoloader 不能直接用于部署脚本，因它不清理 composer.lock 中残留的 require-dev 记录；安全做法是先删 composer.json 中 require-dev 段，再执行 composer update --no-dev --lock 生成纯净 lock 文件，最后用 composer install --no-dev --optimize-autoloader --no-scripts --no-progress 部署。
composer install --no-dev --optimize-autoloader 为什么不能直接用在部署脚本里？
因为 composer install 默认读取 composer.lock，而这个文件里仍包含 dev 包的记录（哪怕没安装）。如果本地开发时没清过 lock，或者团队成员执行过 composer update 但没加 --no-dev，lock 文件就可能残留 require-dev 的哈希或版本约束——这时 --no-dev 只跳过安装，不清理 lock 中的 dev 依赖声明，后续 CI/CD 或他人复现时容易误判依赖范围。
- 真正安全的做法是：先确保
composer.lock本身不含dev信息，再运行安装命令 -
composer install --no-dev不会修改 lock 文件；它只是“按 lock 装，但跳过 dev 部分” - 如果 lock 文件里有
require-dev字段且非空，--no-dev仅抑制安装行为，不校验其存在是否合理
如何生成只含生产依赖的 clean composer.lock？
必须从源头剥离 dev 依赖的痕迹，不是靠安装参数掩盖。核心动作是：删掉 composer.json 里的 require-dev 段，再重生成 lock。
- 手动删掉
composer.json中的"require-dev": { ... }整个字段（包括花括号），保留"require"和其它必要字段 - 运行
composer update --no-dev --lock（注意不是install）：它会重新解析composer.json，生成一个不含任何dev相关元数据的composer.lock - 验证：打开新生成的
composer.lock，确认里面没有require-dev键，且packages数组长度明显少于原版 - 别用
composer update --no-dev不带--lock，它会更新所有包，破坏可重现性
--optimize-autoloader 到底优化了什么？什么时候反而拖慢启动？
它把 PSR-4/PSR-0 映射合并成一张静态数组，跳过 Composer 自动加载器的路径扫描和正则匹配。但前提是你的代码结构规整、命名空间与目录严格对应；否则优化后反而找不到类。
- 生效条件：项目中所有 autoload 规则都来自
composer.json的autoload字段，且无运行时动态注册加载器 - 典型翻车场景：用了
classmap但没跑composer dump-autoload --optimize，或某些包在vendor里自带autoload_files，这些不会被--optimize-autoloader收录 - PHP 7.4+ + OPcache 开启时，优化收益变小；但对 CLI 命令（如 Laravel Artisan）仍有明显提升
- 如果项目混用
include、eval或反射加载类，优化后可能报Class not found，因为 autoloader 不再 fallback 到文件系统探测
部署时推荐的一行稳定命令是什么？
不是简单拼接两个 flag，而是组合动作闭环：基于 clean lock 安装 + 强制优化 + 禁用脚本。最简可靠写法是：
composer install --no-dev --optimize-autoloader --no-scripts --no-progress
-
--no-scripts关键：避免post-install-cmd等钩子意外触发开发专用逻辑（比如生成 mock 数据、跑 phpunit 配置） -
--no-progress减少日志干扰，尤其在容器化环境里避免 ANSI 控制符污染 stdout - 不要加
--ignore-platform-reqs，除非你明确知道 PHP 扩展缺失不影响运行——它会让ext-gd这类硬依赖失效而不报错 - 如果使用 Docker，建议把
composer install放在构建阶段最后一步，并COPY composer.lock composer.json ./后立即执行，避免缓存污染
复杂点在于 lock 文件的生命周期管理：它不该由某个人手动删 require-dev 后提交，而应纳入 CI 流程自动裁剪。否则每次部署前还得人工核对 JSON 结构，漏删一个字段，--no-dev 就形同虚设。
