最可靠方式是用composer require vendor/package:old-version降级，它只更新目标包及直系依赖，不扰动整个依赖树；composer update --rollback命令不存在，Composer无依赖操作日志，无法自动回滚。
直接用 composer require vendor/package:old-version 降级指定包，比删 lock、改 json、瞎 update 更可靠——它只动目标包及其直系依赖，不扰动整个依赖树。
为什么不能用 composer update --rollback
这命令根本不存在。Composer 没有操作日志，也不记录“上一次 update 装了啥”。composer update 每次都从头算依赖图，只看当前 composer.json 和仓库最新可用版本，没有“历史快照”可回。
-
composer self-update --rollback是针对 Composer 自身二进制文件的，和项目依赖完全无关 - 网上搜到的
composer update --lock不是回滚，而是强制重写composer.lock，可能把其他包也升级了 - 手动改
composer.json版本号后跑composer update，容易因依赖冲突失败，尤其当其他包已隐式拉高该包版本时
精准降级一个包的正确流程
以修复 monolog/monolog 升级后报错为例：
- 先查当前装的是啥：
composer show monolog/monolog - 再看它有哪些历史版本：
composer show -a monolog/monolog（注意带-a） - 选一个已知稳定的旧版，比如
^2.9.0，执行：composer require monolog/monolog:^2.9.0 - 如果提示冲突，运行
composer why monolog/monolog找出谁在强依赖更高版，再决定是否一并调整那个包
执行完后，composer.lock 会自动更新，但只改这一项及它的子依赖，其余包版本完全不动。
回滚失败时最常忽略的三个点
很多“明明降级了却还报错”的情况，其实卡在这儿：
-
vendor/autoload.php被 OPcache 缓存了：即使vendor重装了，旧类还在内存里，得清 OPcache 或重启 PHP-FPM / Apache - PHP 版本不匹配：旧版包可能要求 PHP 7.4，而你本地是 8.2，
composer install不报错，但运行时报Fatal error - 没提交
composer.lock：只改了composer.json就跑composer install，结果别人拉代码后装的还是旧 lock 里的版本
真正要“回到上次 deploy 的状态”，唯一靠谱的方式是：用 Git 找到上一次成功的 composer.lock，删掉 vendor，再 composer install。别指望靠命令自动猜出你想要哪个历史节点。
