Composer 本身出错即退出，脚本继续执行是因 shell 未检查退出码；应在脚本开头加 set -e 或用 && || 显式判断，避免 || true 掩盖错误，并注意环境差异与日志可见性。
composer install 或 update 失败时为什么还在继续执行？
默认情况下，composer install 和 composer update 在遇到包安装失败、依赖冲突或网络错误时会报错退出，但如果你把它写在 shell 脚本里（比如 CI/CD 的 .gitlab-ci.yml 或 deploy.sh），没加控制逻辑，后续命令仍可能运行——这不是 Composer 本身“不停止”，而是 shell 默认不检查上一条命令的退出码。
如何让脚本在 composer 命令失败时立即终止？
核心是确保 shell 知道该看 $? 并响应非零退出码。Composer 自身没有 --fail-fast 这类开关，它已经做到了“出错即退出”，问题在调用它的上下文。
- 在 bash/sh 脚本开头加
set -e：任何命令返回非 0 就终止脚本 - 显式检查退出码：
composer install && echo "OK" || exit 1 - CI 配置中避免用
|| true或ignore_errors: true这类掩盖失败的写法 - GitLab CI 示例：
script: - set -e - composer install --no-interaction
，去掉set -e就可能跳过错误继续
哪些情况会让 composer 看似“没停止”，其实是误判？
常见假象：命令行输出了红色错误但脚本继续跑了——大概率是 Composer 实际已退出（返回码非 0），但上层脚本没捕获。
-
composer require some/package遇到版本冲突 → 报错并返回 1，set -e下脚本停住 - 网络超时导致
file_get_contents()失败 → Composer 抛异常并退出，返回码为 255 - 用了
composer install --no-interaction --ignore-platform-reqs却漏掉扩展依赖 → 安装完后autoload.php加载失败，这属于运行时错误，不在 Composer 控制范围内，需靠后续测试步骤拦截 - PHP 版本不匹配时，Composer 会提前拒绝执行（如提示 “This package requires php ^8.1”），直接退出，不走安装流程
CI/CD 中最常被忽略的兼容性细节
不同环境 PHP 版本、扩展、甚至 Composer 版本差异，会导致同一行 composer install 在本地成功、CI 失败，且失败后未终止——根源常是环境配置漂移，而非脚本逻辑。
- GitLab Runner 默认可能用 PHP 7.4，而
composer.json要求 8.2 → Composer 直接报错退出，但若 CI 配置里写了before_script: [composer self-update]，得确认更新后的 Composer 是否仍支持旧 PHP（v2.x 要求 PHP >=7.4，v1.x 已停更） - Docker 构建中用
RUN composer install时，Dockerfile 默认不继承 shell 的-e行为，必须显式写成RUN set -e && composer install - Windows Git Bash 下
set -e不生效，得改用cmd /c "composer install && echo OK"类方式做链式判断
真正卡住人的，往往不是 Composer 会不会停，而是你没看见它已经停了——因为日志被滚动刷走，或者错误被重定向到了 /dev/null。
