composer降级包最稳方式是composer require vendor/package:1.2.3 --with-all-dependencies，它强制重写约束、重算依赖并更新lock文件；自身降级用composer self-update --version x.y.z。
Composer 本身没有 downgrade 命令，但降级包最稳的方式就是 composer require vendor/package:1.2.3 —— 它会强制重写约束、重算依赖、更新 composer.lock，且不依赖你手动删文件。
怎么用 require 强制降级一个包
很多人误以为改 composer.json 再跑 composer update 就行，但实际中常失效：Composer 默认只取满足约束的「最新可用」版本，不是你写的那个具体数字。
- 先确认当前装的是哪个版本：
composer show vendor/package - 执行强制指定：
composer require vendor/package:1.2.3 --with-all-dependencies（加--with-all-dependencies是关键，否则子依赖可能卡住） - 如果报 conflict，别急着删
composer.lock—— 先运行composer depends vendor/package查谁在拖后腿 - 降级后务必验证：
composer show vendor/package输出的 version 字段必须是1.2.3.0（Composer 会补零，1.2.3和1.2解析行为不同）
为什么 composer update vendor/package 经常不生效
因为 composer update 只响应 composer.json 中已声明的约束，且默认策略是“升不降”：只要当前已装的版本满足新约束（比如你把 "^2.0" 改成 "^1.8"，但本地还装着 2.1.0），它就认为“已满足”，直接跳过。
- 改完
composer.json后，必须搭配composer update vendor/package，但更推荐直接require—— 它本质是“先删再装”，不看旧状态 - 如果你写了
"vendor/package": "1.2.3"却没生效，检查是否漏了引号（JSON 格式要求字符串必须带双引号） - 某些插件或平台配置（如
config.platform.php）会静默过滤掉不兼容的版本，临时删掉该配置再试一次
降级后 Class not found 或 autoload 失效怎么办
这不是 Composer 没装对，而是 autoloader 缓存没刷新。Composer 从 v2.2 起默认启用 classmap 生成缓存，降级包后旧类名可能被缓存残留。
- 清缓存：
composer dump-autoload（开发环境够用） - 生产环境建议加
-o参数：composer dump-autoload -o - 如果用了 opcache，还得重启 PHP 进程（如
sudo systemctl restart php-fpm或sudo service apache2 reload） - 别跳过这步 —— 很多“降级成功但跑不起来”的问题都卡在这儿
Composer 自身降级和项目 lock 文件的兼容性陷阱
如果你是为适配老 CI 环境而降级 Composer 本身（比如从 2.7 回退到 2.2），注意：v2.7 生成的 composer.lock 文件，v2.2 直接拒绝读取，报错类似 lock file is not compatible with this version。
- 降级 Composer 前，先备份并删掉
composer.lock；降级后再跑composer install重生成 - v2.2 要求 PHP >= 7.2，但你的项目若用了 PHP 8.2 的语法（比如
match表达式），运行时照样报错 —— 降级工具不等于降级运行环境 - CI/CD 中别依赖
composer self-update，网络波动或版本下线会导致构建失败；固定用官方 PHAR 下载地址：https://getcomposer.org/download/2.2.20/composer.phar
真正容易被忽略的点是：降级一个包，往往牵扯三处状态同步——composer.json 里的约束、composer.lock 里的解析结果、vendor/ 目录下的实际文件。少同步一处，下次 composer install 就可能回滚到旧版。
