直接用 $? 读取上一条命令退出码最可靠，需立即保存（如 composer install; exit_code=$?），避免管道或命令分组干扰；Composer 退出码具语义：1通用错误、2依赖冲突、3包不存在、4网络失败、255自身异常。
如何在 Shell 脚本中正确捕获 composer 命令的退出状态
直接用 $? 读取上一条命令的退出码是最可靠的方式，但要注意执行顺序和子 shell 影响。很多脚本里写成 composer install && echo "success" 看似没问题，其实掩盖了真实退出码——一旦失败，&& 后面根本不会执行，你也拿不到 $?。
实操建议：
- 每条
composer命令后立刻保存$?，比如：composer install<br>exit_code=$?
- 避免管道（
|）或命令分组（{}）包裹composer，否则$?返回的是最后一个命令的值，不是composer的 - 如果必须用管道，改用
$PIPESTATUS[0]（Bash）获取第一个命令的退出码
composer 常见非零退出码含义及对应场景
composer 不像普通 CLI 工具只用 1 表示失败，它定义了一套退出码语义，比如 2 是依赖冲突，3 是找不到包，4 是网络错误。忽略具体码值容易把“包不存在”和“网络超时”当成同一类问题处理。
常见情况：
-
1：通用错误（如语法错误、权限不足） -
2：依赖解析失败（your requirements could not be resolved） -
3：包名或版本不存在（Could not find package xxx） -
4：网络请求失败（Failed to download xxx, curl error） -
255：Composer 自身异常（如 vendor/autoload.php 损坏、内存溢出）
在 CI/CD 流水线中判断 composer install 是否真正成功
仅检查退出码不够——有些情况下 composer install 退出码是 0，但实际没装全依赖，比如启用了 --no-scripts 却误以为脚本执行成功，或 platform-check 警告被忽略。
更稳妥的做法：
- 加
--no-interaction --verbose运行，捕获输出中是否出现Installing dependencies和最终的Package operations:统计行 - 执行后检查
vendor/autoload.php是否存在且可读 - 对关键包（如
monolog/monolog）运行composer show monolog/monolog，确认已加载且版本匹配 - 避免依赖
composer.lock文件存在就认为安装成功——它可能比composer.json旧
PHP 脚本中调用 exec() 执行 composer 时如何获取退出状态
exec() 默认不返回退出码，只返回最后一行输出；system() 会打印输出但返回值仍是退出码——这点常被混淆。
正确姿势：
- 用
proc_open()最可控，能同时捕获 stdout/stderr 和退出码 - 若坚持用
exec()，必须传入第三个参数：exec('composer install', $output, $return_code);<br>// $return_code 就是退出状态 - 注意：Windows 下
composer.bat可能多一层 cmd 包装，导致实际退出码被覆盖，建议在 Windows CI 中改用php composer.phar install
退出码本身不带上下文，composer 失败时 stderr 输出才是关键线索。别只盯着 $? 是不是 0，先确保 stderr 没被重定向丢弃——这是最常被忽略的一环。
