执行 composer update vendor/package-name 可单独更新指定包及其直接子依赖，但需依赖 composer.lock 文件参与解析，且可能连带升级间接依赖；应先用 --dry-run 预览、检查平台配置兼容性，并结合 CHANGELOG 与测试验证。
composer update 只更新某个包，不是靠删 vendor 后重装
直接运行 composer update vendor/package-name 就行，比如想只更新 monolog/monolog，就执行：
composer update monolog/monolog。它不会碰其他依赖，Composer 会按
composer.json 中声明的版本约束重新解析该包及其子依赖（仅限它直接引入的那些），再拉取满足条件的最新版。
版本锁文件（composer.lock）必须参与，不能跳过
很多人以为加 --no-update-lock 或删掉 composer.lock 能“轻量更新”，其实不行——composer.lock 是解析依赖图的依据。手动改 composer.json 版本号后只跑 composer install 也不生效，因为 install 完全以 lock 文件为准。正确流程是：
- 改
composer.json里对应包的版本（可选） - 运行
composer update vendor/package-name - 它自动更新
composer.lock中该包及其子树的条目
小心间接依赖被连带升级或降级
composer update vendor/package-name 不是孤立操作：如果这个包的新版本要求更高版本的 psr/log，而你的项目没显式声明 psr/log，Composer 就会把它也一起升上去——哪怕你根本没想动它。常见现象：
- 执行后
composer.lock里几十个包的 hash 都变了 - 测试突然失败，查发现
symfony/polyfill升了小版本，行为有微小差异 - CI 构建报错，提示
class not found，其实是某个被连带更新的 polyfill 移除了废弃方法
composer show vendor/package-name 看当前版本和依赖树；再加 --dry-run 预览实际会动哪些包：composer update monolog/monolog --dry-run
PHP 版本或平台配置不匹配时，update 会静默跳过或报错
如果你本地 PHP 是 8.2，但 composer.json 里写了 "platform": {"php": "7.4"}，而目标包的新版本已放弃支持 7.4，那 composer update vendor/package-name 可能：要么返回空结果（没找到匹配版本），要么报错 Your requirements could not be resolved。检查点：
- 确认
composer.json的config.platform.php和你当前php -v一致 - 用
composer why-not vendor/package-name:new-version查冲突原因 - 临时去掉 platform 配置再试（别忘了改回去）
真正难的不是命令怎么写，而是判断「这个包能不能单独升」——得看它有没有硬编码依赖其他包的特定小版本，或者项目里有没有直接调用它私有 API。这种细节，--dry-run 看不到，得翻 CHANGELOG 和实际跑一遍单元测试。
