Composer install失败后vendor会脏，因其操作非原子：解析依赖→下载→解压→移动→生成autoload→运行脚本，任一环节中断（如网络、磁盘满、权限不足、脚本异常）均导致vendor残留不完整文件、autoload损坏或installed.json不全。
Composer 没有“回滚原子操作”的机制，所有 install/update 操作本身也不是原子的 —— 它会一边下载解压一边写入 vendor，失败时残留文件是常态。
为什么 composer install 失败后 vendor 会脏？
Composer 在执行过程中分多步：解析依赖 → 下载 zip/tar → 解压到临时目录 → 移动到 vendor/ → 执行 autoload 生成 → 运行脚本。任何一步失败（如网络中断、磁盘满、权限不足、post-install-cmd 抛异常），都会导致 vendor/ 处于中间状态。
- 临时文件（
vendor/composer/installed.json可能不完整） - 部分包已解压但未完成 autoload 注册
-
vendor/autoload.php可能生成失败或内容损坏
如何安全地“撤回”一次失败的 composer update？
没有内置回滚，只能靠外部手段还原到已知可靠状态：
- 若使用 Git：运行
git checkout -- vendor/（前提是vendor/未被.gitignore排除；否则无效） - 若保留了上一次成功的
composer.lock：先git checkout -- composer.lock，再composer install --no-scripts（跳过可能出错的脚本） - 手动清理最保险：
rm -rf vendor/ composer.lock，然后从备份或版本记录恢复composer.lock，再重跑composer install - 避免在生产环境直接
update：始终在 CI 或本地确认composer.lock变更后，再部署该 lock 文件
composer install 中脚本失败怎么捕获和处理？
Composer 自身不提供 try/catch，但可通过配置控制行为：
- 用
--no-scripts跳过所有scripts（包括post-install-cmd），后续单独运行并自行加错误处理 - 在
composer.json的scripts中，把 shell 命令改为带判断的写法，例如："post-install-cmd": "php -r \"if (!file_exists('config/db.php')) { exit(1); }\"" - CI 环境建议用
set -e包裹整个安装流程，确保任意命令失败即终止：set -e<br>composer install<br>php artisan config:clear
- 注意：
composer install返回非零退出码仅表示整体失败，无法区分是下载失败、脚本失败还是 autoload 写入失败
真正麻烦的不是“怎么回滚”，而是“怎么提前防止失败扩散”——锁文件校验、vendor 权限预检、脚本幂等化，这些比事后清理重要得多。
