composer update vendor/package-name 可精准升级指定包及其必要子依赖，如 monolog/monolog，不改动其他包；支持多包空格分隔，且遵循 composer.json 版本约束，避免意外主版本跃迁。
composer update 默认会更新 composer.lock 中所有过时包，但你只需要升级某一个——比如 monolog/monolog，又不想牵连 symfony/console 或 guzzlehttp/guzzle。直接指定包名是最稳妥的方式。
用 composer update 加包名精准升级
命令格式就是：composer update vendor/package-name。它只拉取该包及其满足版本约束的最新兼容版本，不会碰其他条目。
- 如果
composer.json里写的是"monolog/monolog": "^2.8"，执行composer update monolog/monolog就只会升到2.x下的最新版（比如2.10.0），不会跳到3.x - 支持多个包，空格分隔：
composer update monolog/monolog guzzlehttp/guzzle - 如果包有子依赖（如
monolog/monolog依赖psr/log），Composer 会一并更新这些「必要子依赖」以保证兼容，但不会升级其他无关包
为什么不用 composer require --update-with-dependencies
这个命令看似能“局部更新”，但它本质是先卸载再重装，且会强制更新该包所有上游依赖（哪怕它们在 composer.lock 里完全没问题），容易引入意外变更。比如 require --update-with-dependencies laravel/framework 可能顺手把 symfony/http-foundation 升到不兼容的主版本。
- 它绕过了
composer.lock的精确锁定逻辑 - 实际行为更接近“局部重装”，不是“局部升级”
- 除非你明确想刷新整个依赖树分支，否则不推荐
升级前检查版本范围和当前锁定位
盲目 update 容易踩坑，尤其当 composer.json 版本约束太宽（如 "^1.0 || ^2.0"）或太窄（如 "1.2.3"）时。
- 先看当前装的是哪个版本：
composer show monolog/monolog - 确认
composer.json里的约束是否合理，避免升级后破坏兼容性 - 加
--dry-run预览变更：composer update monolog/monolog --dry-run，能看到将要修改哪些行、是否涉及主版本跃迁 - 升级后务必运行测试，因为即使小版本也可能含 BC break（比如某些包把 deprecated 方法删了）
真正要注意的是：Composer 的“单个包更新”只保证目标包及其必要子依赖的语义化兼容，不保证项目整体行为不变。有些包的次要版本改动会影响日志格式、HTTP header 处理或异常抛出时机——这些不会体现在 composer.lock 差异里，得靠测试覆盖住。
