应先将共享依赖显式添加到composer.json中再单独更新，如composer require psr/http-message:^2.0 --no-update后执行composer update psr/http-message，避免使用--with-dependencies导致主包连锁升级。
只更新共享依赖，不碰主项目 require 块
想升级一个被多个包共用的底层依赖（比如 psr/http-message、symfony/polyfill-php81），但又不想连带升级 laravel/framework 或 guzzlehttp/guzzle 这类主包，关键不是“升它”，而是“让 Composer 重新计算时只放开它的约束”。
- 直接运行
composer update psr/http-message通常无效——如果它没在composer.json的require中显式声明，Composer 默认不会把它当作更新目标 - 正确做法是先确认它是否已被其他包“间接引入”：
composer show psr/http-message查当前安装版本；再用composer depends psr/http-message看谁在依赖它 - 若它确实只是传递依赖，且你想强制升到某版本（如
^2.0），得先把它加进composer.json的require块：composer require psr/http-message:^2.0 --no-update，再执行composer update psr/http-message - 加
--no-update是为了防止 require 立即触发全量重算；后续单独 update 才能锁定范围
避免 --with-dependencies 连锁升级主包
--with-dependencies 看似安全，实则危险：它会让 Composer 把目标包的所有直系依赖都纳入更新范围。一旦这些依赖和主项目里的包有交集（比如 symfony/console 同时被 laravel/framework 和你正在升的工具包引用），就可能把主包也拖进去。
- 默认不加任何 flag 的
composer update psr/http-message只会更新该包本身及其 被它显式 require 的子依赖（如psr/http-client），不会动symfony/console这类跨包共享项 - 如果你发现升级后
laravel/framework版本变了，大概率是因为你误加了--with-dependencies，或者该共享依赖的新版本和 Laravel 的约束发生冲突，触发了 Composer 的回退重选逻辑 - 验证是否真“没动主包”：升级前后对比
git diff composer.lock，重点看laravel/framework对应的version和source字段是否变化
当共享依赖被硬锁在旧版时怎么解
常见现象是 composer outdated 显示 psr/log 有 v3 更新，但 composer update psr/log 没反应——说明某个已安装包（比如老版本的 monolog/monolog）在 composer.json 里写了 "psr/log": "^1.0"，Composer 就不敢升。
- 先定位阻塞源：
composer prohibits psr/log:^3.0会列出所有阻止升级的包及其约束 - 如果阻塞包是你能控制的（如自己写的私有 SDK），优先升级它；如果不能（如第三方闭源包），就得接受它锁死共享依赖的事实，别强行绕过
- 临时诊断可用
--ignore-platform-reqs，但仅限本地--dry-run查影响，绝不可提交生成的composer.lock - 更稳妥的做法是：不升级共享依赖，转而升级那个“卡住它”的包本身（例如
composer update monolog/monolog --with-dependencies），让它主动带起新版本的psr/log
CI/CD 中必须守住的边界
流水线里最容易越界的地方，就是用 composer install 时没清理干净缓存，或误把 composer update 当成“补丁安装”塞进部署脚本。
- CI 构建阶段必须用
composer install --no-dev，且确保composer.lock已提交——它决定了装什么，不是composer.json - 如果 CI 需要“动态升共享依赖”，应在独立 job 中完成：
composer update psr/http-message && git add composer.lock && git commit -m "chore: bump psr/http-message"，再推送到分支触发下一轮构建 - 禁止在部署脚本中写
composer update xxx——部署环境应只做安装，不做决策；升级决策必须发生在开发或预发阶段，并经测试验证
真正难的不是命令怎么敲，是判断“这个共享依赖值不值得单独升”。很多团队花半天升级 psr/container，结果发现应用根本没用到它的新接口，反而因版本微调触发了 autoloader 冲突。动手前先问一句：这次升级解决了什么具体问题？有没有更小的替代方案？
