Composer install 卡在交互式提示是因为默认启用交互模式，需用 --no-interaction（-n）彻底禁用；部署时应固定使用 --no-interaction --optimize-autoloader --no-dev，并确保 PHP 平台配置一致。
composer install 为什么卡在交互式提示？
因为默认会检测终端是否支持交互，遇到 phpunit、symfony/flex 插件或某些包的 post-install-cmd 脚本时，会主动询问是否启用配置、是否生成模板等——部署环境没 TTY，它却还在等你敲回车。
常见现象：composer install 在 CI/CD 或 ssh 非登录 shell 中挂住，日志停在类似 Do you want to continue? [y/N] 的地方，超时失败。
根本原因不是缺参数，而是 Composer 默认启用交互（interactive mode），哪怕你加了 --quiet 也不影响这个行为。
--quiet 不等于非交互，真正要关的是 --no-interaction
--quiet 只压制输出（比如跳过下载进度条、包列表打印），但不阻止交互逻辑；真正让 Composer 彻底跳过所有用户确认的，是 --no-interaction（可简写为 -n）。
实操建议：
- 部署脚本里永远优先用
composer install --no-interaction --optimize-autoloader --no-dev，三者缺一不可 -
--optimize-autoloader避免运行时动态加载，提升生产性能；不加它，vendor/autoload.php会变慢且可能触发 warning -
--no-dev不仅省空间，还防止phpunit等 dev-only 包的 post-install-cmd 拉起交互流程 - 别依赖
COMPOSER_NO_INTERACTION=1环境变量——它只对部分命令生效，不如显式传参可靠
CI/CD 中还要防 composer.lock 时间戳和平台配置漂移
即使加了 --no-interaction，CI 环境仍可能因 PHP 版本、扩展差异导致 composer install 重生成 vendor/composer/installed.json 或警告「platform requirements mismatch」，进而触发意外交互或失败。
关键控制点：
- 确保 CI 的 PHP 版本与
composer.json中config.platform.php一致，例如："config": {"platform": {"php": "8.2.10"}} - 用
composer install --no-interaction --ignore-platform-reqs是危险操作——它绕过扩展检查，上线后可能直接报Class not found - 部署前校验
composer.lock是否被意外修改：加一行git diff --quiet composer.lock || (echo "lock changed!" && exit 1)
docker 部署时额外注意 /dev/tty 和 STDIN 绑定
Docker 默认不分配 TTY，但某些基础镜像（如 php:alpine）里的 Composer 会误判 STDIN 可读，仍尝试读取输入——这时光靠 --no-interaction 可能不够稳。
稳妥做法：
- 构建阶段用
RUN composer install --no-interaction --optimize-autoloader --no-dev，并确保WORKDIR正确、composer.json和composer.lock已 COPY 进来 - 避免在
ENTRYPOINT或CMD中运行composer install——那是运行时，不是构建时 - 如果必须在容器启动时安装（极少见），加上
强制断开 STDIN：<code>composer install --no-interaction
最常被忽略的一点：本地开发用 composer update 更新 lock 后，忘了提交 composer.lock，导致部署时 Composer 自动降级或升级依赖，触发平台检查和潜在交互。锁文件不是可选的，是部署契约。
