根本原因是composer install默认启用交互式行为（如github oauth确认），而shell脚本运行于非交互终端导致挂起；必须加--no-interaction（-n）并配合--prefer-dist、--optimize-autoloader等参数确保可控执行。
Composer install 在 Shell 脚本里为什么经常卡住或失败
根本原因不是命令本身，而是 composer install 默认会尝试交互式行为（比如询问是否启用 GitHub OAuth token），而 Shell 脚本通常运行在非交互终端（如 CI 环境、crontab 或 ssh -t 执行）中，导致进程挂起等待输入。
实操建议：
- 始终加上
--no-interaction（简写-n），这是最基础且不可省略的开关 - 避免依赖用户家目录下的全局配置（如
~/.composer/auth.json），CI 环境可能没权限读取或根本不存在；改用--auth参数或环境变量COMPOSER_AUTH - 若项目含私有包，提前用
composer config --auth github-oauth.github.com xxx写入 auth 配置，再配合--no-interaction使用
如何让 composer install 在脚本里真正“可控”
可控 = 可预期退出码、可捕获错误、不因网络抖动误判失败。默认行为下，超时、404 包、平台约束不满足都会返回非零码，但有些情况（如部分包安装成功后中断）状态模糊。
实操建议：
- 显式指定安装行为：
composer install --no-interaction --prefer-dist --optimize-autoloader；--prefer-dist减少 git clone 开销，--optimize-autoloader避免后续首次加载慢 - 加超时控制：用
timeout 300 composer install ...（单位秒），防止因 packagist 响应慢无限阻塞 - 检查 lock 文件是否存在：
[ -f composer.lock ] || { echo "Missing composer.lock"; exit 1; }，避免意外执行composer update逻辑 - 不要忽略退出码：用
if ! composer install -n; then echo "Install failed"; exit 1; fi显式处理失败
CI/CD 场景下 Composer install 的典型陷阱
GitLab CI、GitHub Actions、Jenkins 中常见问题不是命令写错，而是环境和缓存策略错配。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
实操建议：
-
vendor/目录绝不提交，但composer.lock必须提交——否则不同机器上install结果不一致 - 利用 Composer 缓存：在 CI 脚本开头加
composer config --global cache-dir "$CI_CACHE_DIR/composer"（以 GitLab CI 为例），并把该路径设为缓存项 - PHP 版本必须匹配
composer.lock中的 platform.php 字段，CI 镜像 PHP 版本不一致会导致install报错 “Your requirements could not be resolved” - 如果用了
platform-check: false（如某些 legacy 项目），需手动确保运行时 PHP 扩展已安装（如mbstring,json），否则autoload.php加载会直接 fatal error
调试 composer install 失败时该看什么
别一上来就重跑整个脚本。Composer 的输出默认较安静，但关键线索藏在细节里。
实操建议：
- 临时加
-v（verbose）或-vv（very verbose）：如composer install -n -vv，能看到具体哪个包解析失败、哪条 constraint 冲突 - 关注真实错误行，不是第一行报错：常看到
Script @php artisan package:discover handling the post-autoload-dump event returned with error code 1，这其实是下游脚本失败，要翻到上面找php artisan执行前的 warning（比如缺少扩展） - 检查
composer diagnose输出：它能快速暴露权限、签名验证、CA 证书等底层问题，在正式install前运行一次很划算 - 网络问题优先查 DNS 和 TLS：某些内网环境无法验证 HTTPS 证书，可临时加
export COMPOSER_DISABLE_TLS=1测试（仅调试，勿上线）
最易被忽略的是 lock 文件时间戳和 vendor 权限的组合问题：本地开发机生成的 composer.lock 若含 Windows 换行符或特殊字符，CI 中 PHP 解析可能出错；而 vendor/ 若由 root 创建、脚本却用普通用户运行，也会静默失败。
