composer require vendor/package:1.2.3 是唯一可靠降级方式，必须写死版本号、加 --with-all-dependencies 参数，并同步更新 composer.lock 与 vendor/；其他方法如 composer update 或仅改 composer.json 均无效。
composer require vendor/package:1.2.3 是唯一可靠降级方式
别用 composer update vendor/package，它默认只升不降；也别手动改 composer.json 后只跑 composer install，那不会触发重装。降级必须让 Composer 显式接受旧版本并重建依赖图。
-
composer require会自动卸载当前版本、写入新版本到composer.json、更新composer.lock、重装vendor/，一步到位 - 版本号必须写死，比如
guzzlehttp/guzzle:7.4.5，不要用^7.4或~7.4.0，否则仍可能装到 7.4.9 - 加
--with-all-dependencies参数，否则子依赖冲突时会被静默跳过，导致运行时报错 - 执行前先确认目标版本存在：
composer show -a vendor/package，注意看是否标abandoned
降级失败时先查 conflict 来源
报 Your requirements could not be resolved 不是网络问题，而是依赖锁死。Composer 不会猜你想要什么，它只按约束硬解。
- 运行
composer why-not vendor/package:1.2.3，它会指出哪个包（比如laravel/framework）要求了更高版本 - 如果
why-not显示一堆dev-包拦路，加--dev查：composer show --dev | grep package - 临时绕过平台检查（仅调试用）：
composer require vendor/package:1.2.3 --ignore-platform-reqs，但别提交到生产环境
PHP 或扩展“降级”不是包操作
虚拟包（如 php、ext-gd、symfony/polyfill-php81）没有真实代码，不能回退。所谓“版本变化”，只是 Composer 解析时匹配了不同实现。
- 想让
symfony/polyfill-php81降级？当普通包处理：composer require symfony/polyfill-php81:^1.28.0 --with-all-dependencies - 想“降级 PHP 版本”？改
composer.json的config.platform.php，例如从"8.2.*"改为"8.1.*"，再跑composer update --with-all-dependencies - 报
ext-gd不可用？不是包能降级的问题——是你本地 PHP 缺扩展。要么装上，要么在platform里临时声明（仅跳过检查，不解决运行时缺失）
降级后必须验证三处一致性
只看 composer.json 里的版本号是无效的。真正生效的是 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 并装对应 vendor - 验证是否生效：
composer show vendor/package看输出的version字段，不是只看composer.json - 最后跑
composer dump-autoload，确保类自动加载映射刷新
实际最常被忽略的点是：composer.lock 和 vendor/ 必须同步更新。只改 composer.json 或只删 vendor/，下次 composer install 仍会按旧 lock 恢复，CI 环境直接拉错版本。
