Composer 不支持自动回滚，失败时仅返回非零退出码并终止；需在外层脚本中捕获 $? 并结合 stderr 判断错误类型，通过备份 vendor、提交 composer.lock、使用 Docker 镜像或软链接等方式实现安全回滚。
Composer 本身不提供自动检测失败回滚能力，所谓“自动回滚”必须由外部流程控制，不是 composer install 自己能决定的。 它执行失败时只返回非零退出码、打印错误到 stderr，然后终止——连 PHP 异常都不抛，更不会触发任何内置恢复逻辑。
为什么不能依赖 composer install --rollback
因为根本不存在这个参数。Composer 没有回滚命令，也没有状态快照机制。它不记录“安装前 vendor 是什么样子”，也不备份旧包。一旦 composer install 成功写入 vendor/，旧文件就被覆盖或删除；失败时则可能留下半残缺的 vendor/，此时手动清理都得靠经验判断。
-
composer install失败 ≠ 可逆操作：它不做原子写入，vendor/目录处于中间态是常态 - 没有
--dry-run的等效安全预检：无法提前验证所有包能否下载、解压、autoload 是否有效 - 依赖解析失败（如 “Your requirements could not be resolved”）发生在网络请求前，但此时
vendor/可能已被清空
真正可行的失败检测点只有 shell 层退出码
所有“自动检测”必须在调用 Composer 的外层脚本里做，靠 $? 捕获退出状态，并结合 stderr 内容分类响应：
- 退出码为
1：常见于依赖冲突、JSON 解析错误、权限不足 - 退出码为
2：通常是网络超时、代理不可达、镜像源返回异常 JSON（比如空响应或无packages字段） - 退出码为
3：锁定文件损坏、composer.lock与vendor/不一致，或审计模块被裁剪（定制版composer.phar） - 不要只看是否非零——要
grep -q "Connection refused\|timed out\|curl error"区分是网络问题还是逻辑错误，前者适合重试，后者必须人工介入
安全兜底必须提前固化版本锚点
回滚的前提是“有东西可滚”。Composer 不存历史，所以你要自己管好上一个可用状态：
- 每次成功
composer install后，立即备份完整vendor/目录（如cp -r vendor vendor-$(date +%Y%m%d-%H%M%S)），或用硬链接节省空间：ln vendor vendor-last-known-good - 把
composer.lock提交进 Git，并打语义化标签（如v2.3.1-deployed），确保回退时能精确还原依赖树 - 若用 Docker 部署，镜像构建阶段就该固定
composer install结果，运行时绝不执行 install —— 回滚就是docker compose up -d切回旧镜像标签 - PHP 应用上线时，用软链接切换
current → releases/20261031-a1b2c3，失败时只需ln -sfn releases/20261028-d4e5f6 current，旧目录毫发无损
镜像源故障时的 failover 不等于回滚，但能防雪崩
Composer 中文镜像源挂了，composer install 会卡死或报错，但这不是部署失败，而是准备阶段中断。此时你不需要回滚代码，只需要降级源：
- 在
composer.json中禁用官方源："packagist.org": false - 按优先级声明多个镜像：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}、{"type": "composer", "url": "https://mirrors.ustc.edu.cn/composer/"}（注意 URL 必须以/结尾） - 健康检查不能只
curl -I，要实测curl -fsSL --max-time 3 https://mirrors.xxx.com/composer/p2/monolog/monolog.json | jq -e 'has("packages")' - 执行
composer clear-cache再install，避免缓存中残留失效元数据
最易被忽略的一点：回滚动作本身也得可重复、幂等。比如软链接切换要加 -f 和 -n 参数，备份目录命名必须带时间戳或 Git commit hash，否则两次失败后你可能发现 vendor-last-known-good 指向的其实是上次失败的中间态。
