部署脚本中composer install卡住，大概率因缺失--no-interaction参数；该参数强制跳过所有交互确认（有默认值则用默认值，无则报错退出），对install/update/create-project生效，但init不支持，且需配合--no-plugins、--no-scripts等防下游逃逸。
部署脚本里 composer install 卡住，大概率是缺 --no-interaction
CI/CD 或 Docker 构建中，composer install 一卡不动，90% 是因为没加 --no-interaction（或简写 -n）。它不是“可选优化”，而是防止命令在无人值守环境下等待输入的硬性要求。
常见卡点包括：
-
Do you trust "vendor/package" to execute code?—— 第三方包 post-install-cmd 脚本触发信任确认 -
Would you like to run post-install-cmd scripts?—— 默认会问，不加-n就挂起 - 私有镜像源认证失败时弹出密码提示，直接阻塞流水线
正确写法必须带 --no-interaction，且建议前置：
composer install --no-interaction --no-dev --optimize-autoloader --prefer-dist
注意：--no-interaction 对 composer init 无效，但它对 install、update、create-project 都生效；没默认值的交互项（比如 require 版本冲突）仍会报错退出，不是静默吞掉。
为什么只加 -n 还是报错？检查环境变量和插件干扰
COMPOSER_NO_INTERACTION=1 和 --no-interaction 效果等价，但优先级不同：环境变量全局生效，命令行参数仅作用于当前调用。两者混用没问题，但若仍失败，大概率是下游行为逃逸了控制。
典型逃逸点：
- 第三方插件（如
hirak/prestissimo）在初始化阶段尝试绑定本地 socket，触发权限交互 - 自定义脚本里用了
$input->ask()但没判断$input->isInteractive()，导致强制弹出 -
auth.json缺失或属主为root，Composer 在读取时卡在文件权限校验
快速验证方式：
composer install --no-interaction --no-plugins --no-scripts
如果这行能过，说明问题出在插件或脚本环节，而非 Composer 主流程。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
CI 脚本里执行 composer install，为什么还是走官方源？
部署脚本里明明写了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，但 composer install -vvv 日志里请求的仍是 packagist.org —— 这说明镜像配置根本没生效。
关键检查项：
- 是否漏了
-g？没加就是改当前项目composer.json，换目录即失效 - 是否被项目级
"repositories"覆盖？哪怕只是空数组[]，也会屏蔽全局镜像 - CI 环境用户和配置用户不一致：比如用
root配的全局镜像，但构建跑在www用户下
安全做法是：每次部署前先清现场再重配：
rm -f composer.lock vendor/<br>composer clear-cache<br>composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/<br>composer install --no-interaction --no-dev --optimize-autoloader
权限错误不是 chmod 不够，而是 vendor/ 属主错了
报 Permission denied 写 vendor/autoload.php，别急着 chmod -R 777，那只会放大风险。真实原因是 vendor/ 目录被 sudo composer install 污染过，属主变成 root，而后续命令以普通用户运行。
确认方式：
ls -ld vendor/
如果输出含 root root，就立刻修复：
sudo chown -R $USER:$USER vendor/
同理检查：
-
composer.lock：若也属root，一并修复 -
~/.composer/auth.json和~/.composer/cache：属主错位会导致读写卡在认证环节
修复后务必用 composer install --no-scripts 测试基础结构生成能力，再补运行脚本。
