直接运行 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，实际部署时可能报错。
