--no-interaction仅能跳过有默认值的交互（如删vendor、跳过脚本确认），无法处理无默认值的输入（如私有包认证）；CI卡住主因是下游脚本未检查isInteractive()、auth.json缺失或composer init等不支持该参数的命令；稳定方案需组合--no-scripts、预置auth.json、COMPOSER_NO_INTERACTION=1及完整composer.lock。
composer install 的交互提示不能“关闭”，只能跳过——前提是命令本身支持非交互路径，且环境已预置必要条件。
哪些交互能被 --no-interaction 跳过
该参数只对明确设计了默认行为的交互点生效，比如：
- 询问是否删除现有
vendor/目录（有默认值y，会直接删） - 执行
post-install-cmd脚本前确认（跳过，不运行） -
create-project时选版本（用dev-main或stable默认分支）
但它无法处理没有默认值的输入，例如私有包认证缺失时弹出的 token 输入框、某些 SDK 强制要求的 license 确认 —— 此时会直接报错退出，不是卡住。
为什么加了 -n 还在 CI 里卡住
常见真实原因不是参数没起作用，而是：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 下游插件（如
phpstan/extension-installer）内部调用了$input->ask()，但未检查isInteractive() - 私有仓库未配置
auth.json，Composer 尝试从 STDIN 读取密码，而--no-interaction不影响这种底层读取 - 使用了
composer init类命令（它根本不支持-n，加了也报错） - 脚本中硬编码了
readline()或fgets(STDIN)，绕过了 Composer 的交互控制层
真正稳定的非交互安装组合
单靠 --no-interaction 不够，必须配套以下任一或多项：
- 提前写好
auth.json并挂载到COMPOSER_HOME目录下（如/root/.composer/auth.json） - 用
--no-scripts彻底屏蔽所有post-install-cmd类脚本（很多交互来自这些脚本） - 设环境变量
COMPOSER_NO_INTERACTION=1（和-n等效，但更易在 Dockerfile 或 CI 配置中统一控制） - 确保
composer.lock已提交且完整 —— 缺失 lock 文件时，install会退化为update行为，触发更多潜在交互
典型安全命令是：composer install --no-interaction --no-scripts --prefer-dist --optimize-autoloader
别碰的“捷径”
试图用 --ignore-platform-reqs 或 COMPOSER_DISABLE_NETWORK=1 来绕过交互，通常只是掩盖问题：前者可能让不兼容包强行装上并引发运行时错误，后者会让安全通告校验失败，同时阻断所有远程包下载。真正的交互根源几乎总是认证缺失、脚本逻辑缺陷或 lock 文件不一致 —— 这些没法靠开关参数绕过去。
