直接运行 composer update vendor/package-name 即可只更新指定包，其他依赖保持当前锁定版本不变；Composer 默认采用“最小变更”策略，仅解析该包及其子依赖的最新兼容版本，不升级 composer.lock 中已固定版本的其他顶层依赖。

直接运行 composer update vendor/package-name 即可只更新指定包，其他依赖保持当前锁定版本不变。

为什么 composer update foo/bar 不会升级间接依赖？

Composer 默认采用“最小变更”策略：当只指定一个包时，它只解析该包及其子依赖的最新兼容版本，但不会主动升级 composer.lock 中已固定版本的其他顶层依赖（即你在 require 里显式声明的包）。

• 间接依赖（如 foo/bar 所需的 monolog/monolog）可能被连带更新，前提是它们未被你显式 require 且新版本仍满足所有约束
• 如果你在 composer.json 中已写死 "monolog/monolog": "2.9.0"，那它就不会动
• 执行后务必检查 composer.lock 变更，确认只有预期条目被修改

避免意外升级：用 --with-dependencies 要谨慎

这个选项会让 Composer 同时更新目标包的全部直接依赖（即它的 require 列表），容易引发连锁升级。多数情况下不需要加它。

• 默认行为（不加任何 flag）最安全：只升 foo/bar 和它必须换掉的底层依赖（如 PHP 扩展要求变化）
• 加了 --with-dependencies 后，foo/bar 的每个 require 都会尝试升到最新兼容版——哪怕你项目里根本没直接用到它们
• 若真需要控制其依赖版本，应在 composer.json 中显式 require 并锁死，而不是依赖 --with-dependencies

常见错误：误用 composer require 替代 update

composer require vendor/package:version 是安装或修改 composer.json 中的声明，不是“更新已有包”。它会触发整棵树重解析，可能升级大量无关包。

• 想升到特定版本？用 composer update vendor/package --with-all-dependencies（注意是 --with-all-dependencies，不是 --with-dependencies）
• 只是想升最新稳定版？就用 composer update vendor/package
• 执行前建议先 git add composer.lock && git commit -m "save lock before update"，方便出错回退

composer update laravel/framework
# 只更新 laravel/framework，不碰 guzzlehttp/guzzle、symfony/* 等其他顶层依赖

真正容易被忽略的是：某些包的更新会隐式要求 PHP 版本提升或扩展启用，而 Composer 不会在仅更新单个包时强制校验全局环境——它只检查 composer.json 中的 platform 配置。如果没配 platform.php，实际部署时可能报错。

# php  # laravel  # js  # git  # json  # composer  # 为什么  # require  # 你在  # 它只  # 其子  # 的是  # 不需要  # 已有  # 会在  # 所需  # 会让  # 应在