Composer 支持直接降级自身：用 composer self-update --version x.y.z 可回退至任意官方发布的旧稳定版，无需卸载重装或手动下载 PHAR；--rollback 仅限上一版本且不可靠。
composer self-update --version 能直接回退到旧版
Composer 本身支持降级安装自身，不用卸载重装，也不用手动下载 PHAR 文件——只要目标版本是官方发布过的稳定版，composer self-update --version x.y.z 就能搞定。
- 执行前先确认当前版本：
composer --version，避免误操作 - 比如想回到 v2.5.8，就运行：
composer self-update --version 2.5.8 - 国内用户常卡在 SSL 或超时，本质是它默认访问
https://getcomposer.org；可临时配代理或改用export COMPOSER_HOME=~/.composer后手动下载 release 包替换（路径用which composer查） -
composer self-update --rollback只能回退上一个版本，不可指定，且失败时无提示，不推荐依赖它
降级扩展包最稳的方式是 composer require vendor/package:1.2.3
别找 composer downgrade——这命令根本不存在。真正可靠、自动处理依赖、更新 composer.lock 的方式，就是用 composer require 强制重写版本约束。
- 例如把
guzzlehttp/guzzle从 7.8.0 降到 7.4.5：composer require guzzlehttp/guzzle:7.4.5 - 它会自动卸载旧版、装新版、重算依赖图、更新 lock 文件，比手动改
composer.json更少出错 - 如果报
Your requirements could not be resolved，不是网络问题，而是依赖冲突：其他包可能硬性要求高版本；此时加--with-all-dependencies让 Composer 一并调整传递依赖 - 不要写
^7.4或~7.4.0，这些仍可能装到 7.4.9——要精确降级，就得写死7.4.5
手动改 composer.json + update 是可控但易漏的方案
适合批量调整、需要留注释说明原因、或想保留一点版本弹性的情况，但容易忽略锁文件和 vendor 实际状态是否同步。
- 打开
composer.json，把"vendor/package": "^2.3"改成"vendor/package": "~2.2.0"或"2.2.4" - 只更新该包：
composer update vendor/package；千万别跑无参数的composer update，否则所有包都可能被意外升级 - 改完后必须验证三处一致：
composer show vendor/package显示版本、vendor/vendor/package/composer.json中的version字段、composer.lock里对应项的version和reference - 如果之前没提交过
composer.lock，降级后记得git add composer.json composer.lock，否则团队其他人composer install还是旧版
回滚失败时优先查依赖链和 PHP 兼容性
降级失败往往不是命令写错了，而是底层约束不满足——尤其当你退到较老的主版本时。
- 先运行
composer why vendor/package，看谁在强依赖它；再查那个“上游”包的composer.json，它的require是否锁死了高版本 - 旧版包可能要求 PHP composer show vendor/package 会显示其
php约束，别跳过这步 - 有些包在旧版里 API 已移除（比如
getLogger()改成logger()），光看安装成功没用，得跑测试或关键流程验证 - 线上紧急回滚？如果有 Git 历史里的旧
composer.lock，直接git checkout HEAD~2 -- composer.lock && composer install最快，但注意这不会改composer.json，后续update可能又升回去
降级从来不是“换行命令就完事”，真正麻烦的是依赖图里看不见的耦合——一个包退了，可能连带暴露另一个包的兼容 bug，或者让 CI 流水线突然卡在 PHP 类型检查上。动手前多看一眼 composer show -a 和 CHANGELOG，比事后 debug 省两小时。
