最稳方式是用composer require vendor/package:version --with-all-dependencies强制降级，它重写约束、重算依赖并更新lock文件；彻底恢复用composer install，前提是composer.lock未被篡改。
回滚某个包到指定版本用 composer require
直接改 composer.json 里的版本号再 composer install 很容易出错——Composer 可能拒绝降级，或因依赖冲突卡住。最稳的方式是用 composer require 强制重装目标版本：
composer require monolog/monolog:^2.9
它会自动计算兼容性、卸载高版本、装入指定版本，并更新 composer.json 和 composer.lock。如果该包已存在且版本更高，这命令等价于“降级+重锁”。
彻底恢复到上次 composer.lock 状态用 composer install
只要 composer.lock 文件没被删或改写，composer install 就能 100% 复现当时所有包的精确版本（包括嵌套依赖）。注意：composer update 会改写 lock 文件，一旦执行就不可逆回退——所以日常开发中，composer install 才是恢复项目的正解，不是 update。
误执行 composer update 后怎么抢救
如果刚手滑运行了 composer update，lock 文件已被覆盖，但 Git 还没提交，立刻做三件事：
- 用
git checkout -- composer.lock撤销 lock 文件修改 - 运行
composer install重建 vendor - 检查
git status，确认只有 lock 文件被还原，没有意外的代码变更
如果 lock 文件已被提交，就从上一个 commit 中 git show HEAD~1:composer.lock > composer.lock 恢复，再 install。
想回滚多个包或批量降级？别硬写版本号
手动在 composer.json 里挨个改版本极易漏掉间接依赖，而且 Composer 不保证这些组合能解析成功。更可靠的做法是：
- 先用
composer show --tree查当前依赖树，定位哪些包需要动 - 对每个目标包单独执行
composer require vendor/name:version（比如composer require guzzlehttp/guzzle:7.4.5） - 每执行一次就验证功能，避免一次改太多引发隐性不兼容
跨大版本降级（如 Laravel 10 → 9）必须查官方升级指南，光靠 Composer 命令无法处理框架级 breaking change。
真正关键的不是“怎么输命令”，而是始终把 composer.lock 当作项目状态的唯一可信源——它比 composer.json 更精确，也比记忆更可靠。每次 update 前记得 git add composer.lock 并提交，否则回滚时连锚点都没有。
