最可靠方式是用 composer require 锁定旧版本：先查当前版本（composer show），再查历史版本（composer show -a），然后执行 composer require vendor/package:old-version --with-all-dependencies，最后验证并清 autoload 缓存。
直接用 composer require 锁定旧版本最可靠
Composer 没有 rollback 或 downgrade 命令，所谓“回退包”，本质是让 Composer 重新解析依赖并装上你指定的旧版——composer require vendor/package:1.2.3 --with-all-dependencies 就是目前最可控、最常用的方式。
- 先查当前装的是啥：
composer show monolog/monolog - 再看它有哪些历史版本：
composer show -a monolog/monolog（输出里找v2.2.4这类稳定 tag） - 执行降级：
composer require monolog/monolog:2.2.4 --with-all-dependencies，加--with-all-dependencies是关键，否则子依赖冲突时会静默失败 - 完成后立刻验证：
composer show monolog/monolog确认输出是2.2.4，再跑测试或手动触发相关功能
别手改 composer.lock，99% 会出 autoload 错误
有人想省事，直接打开 composer.lock 把 "version": "2.3.1" 改成 "2.2.4"，再填上旧的 dist.sha256 ——这几乎一定失败。因为 Composer 不校验 lock 文件和 vendor 实际内容是否匹配，但 autoloader 会按 lock 里的 classmap 生成映射，一旦 zip 包内容和旧哈希不一致，就会 Class not found。
-
composer install只读 lock 下载包，不校验你手填的哈希是否真对应那个 zip - 如果 Packagist 已下架该旧版 zip（比如作者 yank 了
v2.2.4），Composer 会 fallback 到 source 安装，结果还是装了新版 - 真正安全的做法：用
git checkout还原上一个好用的composer.lock，再rm -rf vendor && composer install
composer update vendor/package 经常没反应？检查三件事
执行 composer update monolog/monolog 后发现 vendor/ 没变、composer.lock 的哈希还是旧的，不是命令没用，而是被几个隐藏条件拦住了。
- 检查
composer.json里该包的约束是否允许目标版本：比如写的是"^2.3"，你就没法靠 update 退到2.2.x，得先改成"~2.2.0"或"2.2.4" - 加
-v看详细日志：composer update monolog/monolog -v，留意有没有Skipping monolog/monolog (already at 2.3.1) - 确认 PHP 版本兼容性：如果项目
config.platform.php设为"8.2"，而你想退的v2.2.4最高只支持php: ^7.2 || ^8.0，Composer 会直接跳过
回退后 Class not found？清缓存比重装更关键
降级成功、composer show 显示版本对了，但运行时报 Class 'Monolog\Logger' not found——这不是包没装对，是 autoloader 缓存没更新。
- PHP 8.0+ 默认启用 opcache，且 Composer 生成的
vendor/autoload.php会被缓存，改了包不等于自动重加载 - 必须执行：
composer dump-autoload（重建 classmap） + 清 opcache（opcache_reset()或重启 php-fpm） - CI/CD 或 Docker 构建中容易漏掉这步，导致测试通过但线上报错
Composer 回退依赖从来不是“撤销一次操作”，而是重新声明 + 重算依赖 + 清理环境。最容易被忽略的，是以为 composer update 能倒着走，其实它只向前找满足约束的最新版；还有就是降级后不碰 autoload，结果代码全在 vendor 里，却根本加载不到。
