根本原因是composer严格遵守composer.json版本约束和composer.lock锁文件逻辑；若指定包未升级，通常是被其他依赖强制约束、platform配置不匹配或锁文件已满足当前约束。
为什么 composer update 不升级指定包？
根本原因不是 Composer 拒绝升级，而是它严格遵守了 composer.json 中的版本约束和已安装依赖的锁文件（composer.lock）逻辑。当你运行 composer update vendor/package 却没生效，大概率是该包被其他已安装依赖的 require 约束死锁住了——比如某个 v2.x 的包强制要求 "vendor/dependency": "^1.5"，而你想升到 2.0，就会触发冲突。
实操建议：
- 先运行
composer why vendor/package，看谁在依赖它；再用composer prohibits vendor/package:2.0.0直接列出所有阻止升级的依赖链 - 检查
composer.lock里该包当前解析出的实际版本，别只信composer show显示的“可用版本” - 如果项目中存在
platform配置（如"php": "8.1"），而新包要求php >=8.2，也会静默跳过升级
如何绕过冲突强行升级（谨慎使用）
强行升级不是推荐做法，但在测试或临时验证时有用。关键是要理解「绕过」不等于「忽略依赖关系」，而是让 Composer 重新计算满足条件的新解空间。
实操建议：
- 删掉
composer.lock和vendor/后再运行composer install—— 这是最干净的重算起点，但会影响全量依赖，慎用于生产环境 - 用
composer update vendor/package --with-all-dependencies让 Composer 尝试连带升级其上下游（注意：可能升级一堆你没意识到的间接依赖） - 若只想升一个包且确认兼容，可临时改
composer.json的require行为"vendor/package": "2.0.0 as 1.9.9"（即版本别名），骗过语义化版本检查——仅限调试，不可提交
composer update 与 composer require 的行为差异
很多人以为 composer require vendor/package:^2.0 就能升级，其实它本质是「添加新依赖」操作：如果包已存在，Composer 默认不会降级或跨主版本升级，除非显式加 --update-with-dependencies。
常见错误现象：
- 执行
composer require vendor/package:^2.0后版本没变，因为旧版仍满足约束（例如原为^1.8，而^2.0是不兼容的主版本） -
composer update默认只更新composer.lock中已有条目，不拉取新包；composer require才会修改composer.json并触发重装 - 如果
composer.json里写的是"vendor/package": "dev-main"，composer update可能一直卡在 dev 分支，而非切到稳定 tag
锁定 PHP 或扩展版本引发的隐性冲突
Composer 2.2+ 开始默认启用 platform-check，它会校验 composer.json 中 config.platform 声明的 PHP、扩展版本是否与当前运行环境一致。一旦不匹配，某些包的高版本会被直接过滤掉，连 prohibits 都不报——你以为是依赖冲突，其实是平台不匹配。
排查方法：
- 运行
composer config platform.php和php -v对比，确认是否人为锁定了过低的 PHP 版本 - 检查
config.platform.ext-mbstring等扩展声明，如果设为"1"但实际是"8.1.0"，也可能导致解析失败 - 临时禁用平台检查：
composer update --ignore-platform-reqs（仅用于定位问题，不要长期使用）
真正卡住升级的，往往不是某个包本身，而是它某一层间接依赖里藏着一个未声明却强绑定的 php 版本，或者一个被 platform 锁死的扩展版本号。每次遇到“升不动”，先跑一遍 composer prohibits 和 composer config platform，比反复删 lock 文件更快。
