composer install 在 CI/CD 中卡住是因为默认读取 stdin 等待用户输入，解决方法是使用 --no-interaction（-n）强制静默运行，并配合 --prefer-dist 和 --optimize-autoloader 提升性能，同时确保 composer.lock 存在、缓存启用及私有仓库认证已配置。
composer install 为什么在 CI/CD 中卡住？
因为默认会读取 stdin 等待用户输入，比如遇到 vendor/autoload.php 不存在、或需要确认是否删除旧包时，composer install 会停在交互式提示上，导致自动化脚本挂起。
--no-interaction 是核心开关
加上 --no-interaction（可简写为 -n）能强制跳过所有交互逻辑，让命令完全静默运行。它不只是“不显示提示”，而是从根本上禁用所有需人工干预的分支路径。
- 即使
composer.json缺失或格式错误，也会直接报错退出，不会尝试引导你初始化 - 遇到已安装但版本冲突的包，不会问“是否强制重装”，而是按策略直接失败或覆盖（取决于其他参数）
- 与
--no-ansi配合使用可进一步去掉颜色输出，适合日志归档
composer install --no-interaction --no-ansi
必须配合 --prefer-dist 和 --optimize-autoloader
在非交互模式下，Composer 不会自动启用优化选项，而它们对构建速度和运行时性能影响显著：
-
--prefer-dist强制从压缩包安装（而非克隆 Git），大幅减少网络和解压耗时 -
--optimize-autoloader生成扁平化类映射，避免运行时遍历psr-4命名空间 - 这两个参数在交互模式下可能被跳过或降级，但在
--no-interaction下必须显式声明才生效
composer install --no-interaction --prefer-dist --optimize-autoloader
CI 环境还要注意 cache 和 lock 文件
静默安装不是万能的——如果 composer.lock 不存在或过期，--no-interaction 会让 install 直接失败（不会自动 update）。常见错误信息是：Package operations: 0 installs, 0 updates, 0 removals 却没报错，实际是啥都没做。
- 确保 CI 流水线中
composer.lock已提交且未被忽略 - 若需动态更新依赖，改用
composer update --no-interaction --prefer-dist，但要承担不确定性风险 - 建议在 CI 中启用 Composer cache（如 GitHub Actions 的
php-actions/composer或自建COMPOSER_CACHE_DIR）
最易被忽略的是：某些私有仓库认证（如 GitHub Token）未通过 auth.json 或环境变量注入时，--no-interaction 会让认证失败静默跳过，最终报错找不到包——此时需提前验证 composer config -g github-oauth.github.com <token></token> 是否生效。
