Composer默认只升不降，因其将版本约束视为最低可接受版本，故update不会主动回退已装版本；必须用require指定具体旧版本并加--with-all-dependencies强制重算依赖图。
不能用 composer update vendor/package 降级，必须用 composer require vendor/package:1.2.3 显式指定旧版本。
为什么 composer update 不会降级
Composer 默认只升不降：update 命令只在当前约束范围内找“最新可用版本”，不会主动往低版本回退。即使 composer.json 里写的是 "^1.0"，它也不会把已装的 1.5.0 换成 1.2.3——除非你强制让它“重新解析并接受更低版本”。
-
composer update vendor/package只更新该包及其子依赖，但仍在原有版本约束内，不突破下限 - 手动改
composer.json中版本号后只跑composer install，不会重装，因为composer.lock还锁着旧版本 - 真正触发降级的唯一可靠动作是
composer require带具体版本 +--with-all-dependencies
执行降级的正确步骤
先确认目标版本存在且兼容，再一次性完成声明、解析、重装、锁定四件事：
- 查可用版本：
composer show -a vendor/package，注意看是否标abandoned - 运行降级命令：
composer require vendor/package:1.2.3 --with-all-dependencies - 若失败，立刻查阻塞项：
composer why-not vendor/package:1.2.3（它会指出哪个包要求了更高版本） - 如阻塞来自 dev 包，加
--dev查：composer show --dev | grep package - 降级后务必验证：
composer show vendor/package看输出的version字段，不是只看composer.json
常见踩坑点：vendor 和 lock 不同步
很多人改完 composer.json 就以为完事了，结果 CI 构建或同事 composer install 时还是装的老版本——因为 composer.lock 没更新，或者 vendor/ 残留了旧文件。
- 安全做法是：删干净
vendor/（rm -rf vendor）+ 删掉或回滚composer.lock（git checkout HEAD -- composer.lock） - 再执行
composer require vendor/package:1.2.3 --with-all-dependencies，它会自动生成新lock并完整重装 - 如果跳过清理直接
require，某些旧文件可能残留，尤其当类名/命名空间没变但行为已改时，问题极难排查
最易被忽略的是：虚拟包（如 symfony/polyfill-php81 或 ext-gd）没有“版本可降级”的概念，它们只是占位符。想“降级 php 版本兼容性”，得改 config.platform.php；想换 polyfill 版本，就当普通包处理——别在虚拟包上浪费时间找回退命令。
