Composer不会主动降级包，所谓“降级”实为约束冲突、PHP版本不匹配、lock文件变更或--prefer-lowest等环境因素导致依赖解析器选出唯一可行旧版本。
Composer 不会“主动”降级包，它只是严格按规则选版本——你看到的“降级”，其实是约束冲突、环境限制或 lock 文件变更后，依赖解析器选出的唯一可行解。
composer install 为什么装了更低版本
这通常不是 Composer 在倒退，而是当前环境迫使它选旧版：
- composer.lock 被删或重生成过：install 只照 lock 装，但 update 或首次 install 会重新解析，可能因新加入的包要求更老的依赖而回退
- PHP 版本不匹配：比如你声明
"php": "8.0"，而某个包的 3.x 版本要求 PHP >=8.1，Composer 就只能选它最后一个支持 8.0 的 2.x 版本 - 间接依赖锁死：A 包要求
monolog/monolog: ^2.0，B 包只兼容monolog/monolog: ^1.25，Composer 只能降级 monolog 到 1.x 来同时满足两者 - 用了
--prefer-lowest：这个 flag 会让 Composer 故意选每个包的最低可用版本，常用于 CI 测试兼容性，但不是默认行为
^ 和 ~ 约束到底允许多大范围升级
符号不是“升到最新”，而是定义一个数学区间，Composer 在里面找最大可行值：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
^2.3.4≡>=2.3.4, ：主版本 2 锁死，次/修订号随便升，但绝不会到 3.0.0 -
^0.5.2≡>=0.5.2, ：0.x 是开发版，次版本升级视为不兼容，只放修订号 -
~2.3.4≡>=2.3.4, ：比 ^ 更保守，连次版本都不让升 - 没符号（如
"monolog/monolog": "1.2.3"）才真正锁死：等价于=1.2.3，后续 install 一定装这个精确版本
为什么改了 composer.json 还不降级
因为 composer update vendor/package 默认只在原有约束内找最新版，不是“执行你心里想的版本”：
- 如果你写的是
"guzzlehttp/guzzle": "^7.5"，update 永远不会装 7.4.5 —— 它认为 7.5.x 已满足约束 - 要让它装旧版，必须先改约束：把
"^7.5"换成"7.4.5"（带双引号），再跑composer update guzzlehttp/guzzle - 更稳妥的做法是直接
composer require guzzlehttp/guzzle:7.4.5 --with-all-dependencies：它会删掉旧包、重算整棵树、更新 lock，不依赖你手动改 JSON - 静默失败常见原因：
config.platform.php声明的 PHP 版本高于目标包支持范围，Composer 会跳过安装且不报错
composer.lock 变了但 vendor 没更新？
lock 文件变只是说明解析结果变了，但 vendor 目录是否同步，取决于你执行的是哪个命令：
-
composer install：只按 lock 装，lock 变了但没运行 install，vendor 就不会动 -
composer update：既重算依赖、更新 lock，也更新 vendor -
composer require xxx：默认也会更新 vendor；加--no-update就只改 composer.json 和 lock，不碰 vendor - 如果 lock 更新了但 vendor 还是旧文件，大概率是没执行 install/update，或者执行时加了
--no-install类参数
最易被忽略的一点：Composer 解析依赖时，config.platform 和本地 PHP 实际版本不一致，会导致它选错包——它信的是 platform 配置，不是你 php -v 输出的结果。
