composer update 只更新指定包需在命令行中指定包名，如 monolog/monolog；开发依赖需加 –dev；多包用空格分隔；–with-dependencies 可递归升级连带依赖；锁定版本须先改 composer.json 再 update；vendor 或 lock 文件不一致时可用 composer update –lock 修复。
composer update 只更新指定包
直接在命令行中指定包名，就能跳过其他依赖，只更新目标包及其满足的最小版本约束。这是最常用也最安全的细粒度控制方式。
常见错误是写错包名（比如漏掉 vendor 名）或混淆了 require 和 require-dev 中的包位置——如果包只在 require-dev 里，不加 --dev 就不会被更新。
- 更新生产依赖中的
monolog/monolog：composer update monolog/monolog - 更新开发依赖中的
phpunit/phpunit：composer update phpunit/phpunit --dev - 同时更新多个包（空格分隔）：
composer update symfony/console symfony/Filesystem
用 –with-dependencies 更新连带依赖
默认情况下，composer update foo/bar 只更新 foo/bar 自身，不升级它的子依赖（哪怕子依赖有新版且符合 composer.json 约束）。这容易导致兼容性隐患或功能缺失。
加上 --with-dependencies 后，Composer 会递归检查并升级所有直接/间接依赖项，只要它们的版本约束允许。
- 安全场景：你刚升级了
guzzlehttp/guzzle，但发现aws/aws-sdk-php内部仍用旧版psr/http-message，这时加--with-dependencies能一并刷新 - 注意副作用：可能意外升级其他包，建议先加
--dry-run预览：composer update guzzlehttp/guzzle --with-dependencies --dry-run
锁定版本号避免自动升级
有时你想“更新”某个包，但不是升到最新兼容版，而是明确切到某一个已知稳定的版本（比如修复了你遇到的 bug 的 patch 版）。
此时不能只靠 composer update，得先改 composer.json，再执行更新命令。
- 编辑
composer.json，把"monolog/monolog": "^2.8"改成"monolog/monolog": "2.9.1"（精确版本）或"monolog/monolog": "~2.9.0"（最小边界） - 然后运行：
composer update monolog/monolog—— Composer 会严格按新约束拉取 - 别用
composer require monolog/monolog:2.9.1替代，它会重写整个require区域，可能覆盖你手动写的其他字段（如sort-packages或注释）
vendor 目录残留导致更新失败
执行 composer update xxx 后发现没变化，或者报 Package xxx is not installed，大概率是 vendor/ 下残留了旧文件，或 composer.lock 和 composer.json 不一致。
这不是命令写错了，而是状态脏了。强行删 vendor/ 和 composer.lock 太暴力；更稳妥的是用 Composer 自带的清理机制。
- 先同步锁文件与 json：
composer update --lock（仅更新 lock，不碰 vendor） - 再单独更新目标包：
composer update xxx --with-dependencies - 若仍失败，可临时清空 vendor 中对应目录：
rm -rf vendor/xxx/yyy，再重试（注意别删错路径）
实际操作中最容易被忽略的是 --with-dependencies 的默认缺失，以及对 composer.lock 状态的误判。很多“更新没生效”的问题，本质是 lock 文件卡在旧快照，而不是命令本身不对。