Composer不会主动降级包，若安装较低版本，通常是因composer.lock被重生成、版本约束不兼容、PHP环境限制或使用了--prefer-lowest选项所致，需检查依赖冲突及环境配置。
当你运行 composer install 时，Composer 并不会主动“降级”包，但如果它安装的版本比你之前使用的低，说明当前的依赖环境或配置导致了这个结果。这通常不是随机发生的，而是由以下几种常见原因引起的。
1. composer.lock 文件被更新或重新生成
如果你执行的是 composer update 后再运行 install，或者删除了 composer.lock 文件，Composer 会根据 composer.json 中的约束重新计算依赖版本。这可能导致某些包被安装为较旧的版本，尤其是当：
- 某些依赖项的新版本不再满足其他包的版本约束。
- 某个间接依赖（依赖的依赖）要求一个更老的主版本。
注意：composer install 应该严格按照 composer.lock 安装指定版本。如果这时出现降级，说明 lock 文件里记录的就是较低版本。
2. 版本约束设置过宽或不兼容
在 composer.json 中，如果你使用了像 ^1.0、~2.1 或通配符（如 *）这样的宽松约束，可能会引入不兼容的更新。反过来，当你添加一个新包，而这个包只兼容某个旧版本的库时，Composer 为了满足所有依赖，只能回退（降级）那个包。
举例：你的项目用了 monolog/monolog:^2.0，但新加入的包只支持 ^1.0，那么 Composer 只能将 monolog 降级到 1.x 系列以满足依赖关系。
3. 平台依赖（PHP 版本或其他扩展）限制
如果你的 PHP 环境版本较低，或者缺少某些扩展，某些新版包可能无法安装。Composer 会自动选择最后一个支持你当前环境的旧版本，看起来就像“降级”了。
比如：某个包的 3.x 版本需要 PHP 8.1+，而你运行的是 PHP 7.4，Composer 就只能选 2.x 的最新兼容版。
4. 使用了 --prefer-lowest 或其他特殊选项
如果你或 CI/CD 脚本中使用了 --prefer-lowest 参数，Composer 会尽可能安装符合约束的最低版本，用于测试兼容性。这会导致很多包被“降级”到最早可用版本。
检查是否在命令中误加了这类参数，例如：
composer install --prefer-lowest
如何排查和解决？
你可以通过以下方式定位问题：
- 查看 composer.lock 文件中的版本变化，确认哪些包被降级。
- 运行 composer why package/name 查看某个包为何被安装（包括版本限制来源）。
- 使用 composer depends package/name 找出哪些包依赖于它，并查看它们的版本要求。
- 检查 PHP 版本和扩展是否与期望安装的包兼容。
基本上就这些情况。Composer 的目标是满足所有依赖约束，哪怕这意味着降低某些包的版本。关键是理清谁在“拉低”版本，然后调整依赖或环境来解决冲突。
