Composer 非交互环境下卡在凭据提示时，应加 -n 参数并设 COMPOSER_NO_INTERACTION=1，预置 http-basic.gitlab.com 或 github-oauth.github.com 凭证，确保 composer.lock 已提交且基础环境（PHP扩展、SSH配置等）完备。
Composer 运行时卡在 Do you want to store credentials for gitlab.com? 怎么办
这是非交互环境下最典型的阻塞点——Composer 在首次访问私有仓库（如 GitLab、GitHub）时，默认会询问是否保存凭据，而 CI/CD 或 Docker 构建中没有 TTY，导致进程挂起或超时失败。
根本解法是彻底禁用交互，让 Composer 用预设行为快速决策：
- 加
-n（--no-interaction）参数：跳过所有 yes/no 提示、凭据存储、模板选择等交互流程 - 确保
COMPOSER_NO_INTERACTION=1环境变量已设置（某些容器或部署工具更依赖该变量） - 若使用
composer install，还需确认composer.lock已提交——否则-n下 Composer 不会自动执行update，缺失 lock 文件将直接报错
为什么 composer install -n 仍提示输入 token？
因为 -n 只跳过“用户确认”，不解决“凭证缺失”问题。当 composer.json 声明了私有仓库（如 "repositories": [{"type": "vcs", "url": "https://gitlab.com/xxx"}]），而 Composer 没有对应认证方式时，它会在非交互下静默失败，但部分版本（尤其是 2.2+）仍可能输出警告或触发 fallback 行为。
正确做法是提前注入凭证：
- 用
composer config --global http-basic.gitlab.com预置 HTTP Basic 认证（适用于 GitLab Personal Access Token） - 对 GitHub，推荐用
github-oauth配置：composer config --global github-oauth.github.com - 若用 SSH 克隆私有包，确保
~/.ssh/id_rsa和known_hosts已就位，且git命令本身支持无密码拉取
composer create-project -n 初始化失败的常见原因
该命令在非交互模式下对模板（template）处理更严格，尤其当目标包含 composer.json 中的 scripts 或 extra 配置时，容易因缺少上下文而中断。
关键检查点：
- 目标项目是否声明了
"type": "project"？否则create-project可能忽略它或报Could not find package - 是否混用了
--stability和--prefer-dist？在-n下，若稳定版不可用又未显式允许dev，会直接退出而非降级尝试 - CI 环境中 PHP 扩展缺失（如
zip、mbstring）会导致create-project解压失败，错误常被掩盖为“空响应”或超时
Docker 构建中 Composer 非交互运行的硬性条件
容器里跑 composer install -n 不等于万事大吉。以下三点漏掉任一，都可能让构建在看似无关的位置卡住：
-
RUN composer install -n --no-dev --optimize-autoloader必须写在单独一层，且前面不能有WORKDIR或COPY导致缓存失效后重新触发交互逻辑 - 确保基础镜像中
composer是全局安装且版本一致（推荐用composer:2官方镜像，避免 Alpine 上的php-composer包版本陈旧） - 如果项目依赖
php-ext-*扩展，需在composer install前完成扩展安装并启用（例如docker-php-ext-install zip），否则-n下 Composer 不会提示缺失，而是静默跳过相关包或报 autoload 错误
自动化场景下，交互不是“要不要关”的问题，而是“必须关死，并补全所有隐式依赖”的问题。任何残留的提示路径（比如插件钩子、自定义脚本里的 readline()）都会让 -n 失效。
