<p> 最直接的回退办法是用 Git 还原 composer.json 和 composer.lock 文件：未 commit 时执行 git checkout — composer.json composer.lock；已 commit 未 push 用 git reset –hard HEAD~1；已 push 则用 git revert 并 composer install。</p>
composer update 后想回退，最直接的办法是 git reset
Composer 本身没有内置的「撤销上一次 update」命令，composer update 修改的是 composer.json 和 composer.lock，而这两份文件通常都纳入了 Git 版本控制。所以真正有效的回滚，其实是还原这两份文件。
- 如果刚执行完
composer update还没git commit：直接运行git checkout -- composer.json composer.lock即可丢弃修改 - 如果已经 commit 了，但还没 push：用
git reset --hard HEAD~1回退上一个提交（注意这会丢弃该 commit 的所有改动） - 如果已 push 到远程，且多人协作：别硬 reset，改用
git revert反转那次提交，再composer install恢复旧 lock 文件状态
只还原依赖包，不改 composer.json 和 lock 文件
有时你只是想让当前 vendor 目录回到上次 composer install 的状态，而 composer.json 和 composer.lock 都没动过——这种情况极少，但真发生了，说明你可能误删了 vendor 或手动改了某些包。
-
composer install会严格按composer.lock安装，只要 lock 文件没变，反复执行它就是最安全的“重装”方式 - 不要用
composer update --lock来“刷新 lock”，它不回退，只会重新生成 lock（可能升级次要版本） - 如果 vendor 已损坏，先
rm -rf vendor再composer install，比试图 patch 更可靠
想退回某个包的旧版本，但又不想全量回滚
这是更常见的需求：比如 monolog/monolog 升级后出问题，其他包没问题。这时候不该动整个 lock，而是精准降级。
- 先查历史版本：
composer show monolog/monolog --all看可用版本列表 - 指定版本安装：
composer require monolog/monolog:^2.9.0（注意用^而非~，避免意外升到 3.x） - 执行后
composer.lock会被更新，但只改这一项及其依赖，其余包保持不变 - 如果提示冲突，说明其他包依赖更高版本——这时得看
composer why monolog/monolog找出谁在拉高版本
为什么不用 composer update –rollback 或类似命令
因为根本不存在。Composer 的设计哲学是「声明式」而非「操作式」：它不记录每次 update 的 diff，也不维护本地操作日志。
-
composer update的行为完全由当前composer.json和仓库可用版本决定，没有“上一次”的上下文 - 所谓“回滚”，本质是回到某个已知、可复现的状态（即某次 commit 中的 json + lock 组合）
- 试图靠
composer outdated手动比对再逐个require旧版，极易漏掉间接依赖或版本约束冲突，不推荐
真正容易被忽略的是：lock 文件里每个包的 source 字段（如 commit hash）决定了实际安装来源。哪怕你 require 了旧版本号，如果 packagist 上该版本已被 yank，或者你用了 private repo 且它删了 tag，依然会失败。
