唯一可靠回滚方法是：Git 恢复旧 composer.lock + 彻底删除 vendor + 运行 composer install；其他方式均会残留错误，因 Composer 不记录历史、只认 lock 文件为唯一真相。
没有“回滚失败升级”的专用命令，唯一可靠路径是：用 Git 还原 composer.lock + 彻底清空 vendor + 重跑 composer install。 其他任何试图“撤销 update”或“跳过重装”的操作，都会留下残留、缓存或 autoload 错误，导致行为不可控。
为什么 composer update --rollback 不存在且不能模拟
Composer 不记录操作历史，也不维护本地变更栈。它只认 composer.lock 文件——这个文件就是当前依赖的“唯一真相”。所谓“失败的升级”，本质是你运行了 composer update，它生成了一个新的 composer.lock，并（可能）部分写入了 vendor/。此时：
-
composer update --lock只会重新计算并覆盖lock文件，完全不碰vendor/，旧代码还在磁盘上，类仍可能被加载 - 手动编辑
composer.lock回填旧版本和哈希是高危行为：一旦 dist URL 或 shasum 与 Packagist 当前实际内容不一致，composer install会静默下载最新版，而非你期望的旧版 -
composer require vendor/package:old-version会触发全新依赖解析，可能连带升级其他包，不是还原，而是另一次不确定的安装
真正生效的三步操作（缺一不可）
这三步必须按顺序、完整执行，中间不能跳过或简化：
-
从 Git 恢复上一个可用的
composer.lock：比如刚update出问题，立刻执行git checkout HEAD~1 -- composer.lock；如果已提交新 lock，就用git checkout abc1234 -- composer.lock（替换为对应 commit hash） -
彻底删除
vendor目录：用rm -rf vendor（Linux/macOS）或rmdir /s vendor（Windows），不能只删子目录或留vendor/autoload.php -
运行
composer install（不是update）：它会严格按刚恢复的composer.lock下载、解压、安装每个包的 exact 版本，并重建 autoload 映射
常见残留问题与验证要点
即使上述三步做完，仍可能因环境残留导致“看似回滚成功，实则行为异常”：
-
opcache未清：PHP 可能仍在执行旧版本类的缓存字节码，需执行opcache_reset()或重启 Web 服务（如sudo systemctl restart php8.2-fpm） -
vendor/bin/下脚本残留：比如旧版phpunit仍存在且在PATH中优先被调用，检查并手动删掉vendor/bin/phpunit等二进制文件 - 第三方钩子未重放：某些包的
post-install-cmd（如生成配置、编译资源）在旧lock对应的安装中会执行，但你只重装了代码没重跑钩子——可手动执行composer run-script post-install-cmd（注意不是所有项目都支持） - 确认是否真还原：运行
composer show vendor/package，对比输出的 version 和 commit hash 是否与 Git 中上一版composer.lock里记录的一致
最关键的细节常被忽略：Git 还原 composer.lock 后，composer install 才是让变化落地的那一步；不执行它，vendor/ 仍是脏的，一切都没变。
