Composer卡住的根本原因是终端不可交互或需确认路径时未加--no-interaction；该参数并非隐藏提示，而是切断等待逻辑，有默认值则使用，无则报错退出。
composer install/update 为什么卡住？
根本原因不是“提示太多”，而是 Composer 检测到终端不可交互（比如 CI 环境无 TTY）或命令本身进入需确认路径（如清空 vendor、覆盖已有文件），却没被告知“别等我”。--no-interaction 不是隐藏提示，是切断等待逻辑——有默认值就用默认值，没默认值就直接报错退出。
加 --no-interaction 的实际效果
它只对部分命令生效，且行为不统一：
-
composer install和composer update：跳过是否生成 autoload、是否清理缓存等确认 -
composer create-project：跳过目录是否清空、是否安装 dev 依赖等交互 -
composer init：加了也无效，报错Interactive mode is required -
composer require：支持，但版本冲突时仍会失败（因无默认可选版本） -
composer dump-autoload：本来就不交互，加了无影响
光加 --no-interaction 还不够
CI 中真正卡住的常见原因，往往不是 Composer 本身，而是下游行为：
- 私有包源未预配置认证，触发 Git 凭据输入（需提前设
COMPOSER_AUTH或用git config --global url."https://token:x-oauth-basic@github.com".insteadOf "https://github.com"） - 插件（如
hirak/prestissimo）在非交互模式下仍尝试弹出提示（应加--no-plugins） - 自定义脚本里用了
$input->ask()，--no-interaction不影响它——得在脚本里主动判断$input->isInteractive()并 fallback - 没配
--prefer-dist，回退到source模式后可能触发 Git clone 交互
稳定写法通常是：composer install --no-interaction --prefer-dist --no-dev --ignore-platform-reqs --no-plugins
环境变量 COMPOSER_NO_INTERACTION=1 算不算数？
算，但仅作为兜底。它等价于全局加 --no-interaction，对所有后续 Composer 命令生效。不过要注意：
- 它不能覆盖命令行显式传入的
--interactive（虽然极少有人这么干） - 它不解决插件或脚本层的交互，只是让 Composer 主流程跳过确认
- 若脚本中手动调用了
exec('composer ...')且没传参，这个环境变量才起作用；如果写了exec('composer install')，那还是得显式加-n
真正容易被忽略的是：某些 Dockerfile 或部署脚本里只设了环境变量，却忘了删掉原来命令里的交互式参数（比如 composer install -v），而 -v 会隐式启用交互模式——这种组合反而让 COMPOSER_NO_INTERACTION=1 失效。
