唯一可靠回滚方法是git恢复旧composer.lock+彻底删除vendor+运行composer install；因composer不记录历史，只认lock文件为唯一真相，其他操作均非真正回滚。
没有 composer update 回滚命令，也不存在 --rollback、--undo 或类似参数。 所有试图用 composer update --lock、composer require 或手动改 composer.json 来“倒退”的操作，本质都是另一次依赖解析，不是回滚。
为什么 composer update --lock 不能回滚
这个命令只读当前 composer.lock 和 composer.json，重新生成 lock 文件——它不查 Git 历史，也不恢复旧状态。常见后果包括：
-
composer.lock格式已变（如 v2.5+ 新增content-hash字段），老版本依赖无法还原 - 本地 PHP 版本或扩展变了，
--lock会静默跳过不兼容包，导致依赖树偏移 - Packagist 上某包的 dist 包被删或重发，
--lock仍会尝试拉新内容，校验失败后可能 fallback 到源码安装 - autoload 映射被新版 Composer 重写，运行时报
Class not found，但composer install看似成功
真正有效的三步 Git 恢复法
前提：你的 composer.lock 提交进了 Git，且出问题前有可追溯的稳定 commit（比如上线 tag 或 merge commit）。
- 用
git checkout <stable-commit-hash> -- composer.lock</stable-commit-hash>拿回旧版 lock 文件（注意保留换行和末尾空行） - 彻底删除
vendor/：rm -rf vendor（Windows 用rmdir /s vendor） - 运行
composer install（不是update），它会严格按 lock 文件下载、解压、校验、安装每个包
这三步缺一不可。少删 vendor，旧类可能还在 opcache 里；少还原 composer.lock，install 就没依据。
没提交 composer.lock 怎么办
Git 历史里找不到，说明你没把它纳入版本控制——这是最常被忽略的根源问题。补救路径有限，且都带风险：
- 查
composer show --installed，看当前装了哪些包和版本，再手动编辑composer.json改约束，然后composer install（但间接依赖可能错配） - 翻 CI 日志或部署记录，找上次成功构建时的
composer.lock内容（如果有存档） - 用
composer-lock-diff工具对比当前 lock 和上一个已知 good commit 的 lock，人工提取差异包降级 - 如果连
composer.json都被动过，先git checkout HEAD -- composer.json，再试上面方法
最麻烦的是：你以为只是某个包出问题，结果 composer why-not 显示它被另一个你没注意的 dev 包强制拉高了版本——这种隐式依赖链，只有完整 lock 文件才能锁定。
