直接在composer update后空格分隔多个已声明包名即可精准批量更新——仅影响所列包及其直系子依赖，不改动其他依赖；Composer不支持通配符（如monolog/*）或引号包裹的多包列表，包名须完整、大小写敏感且已在composer.json中声明。
直接在 composer update 后面空格分隔多个已声明的包名，就能一次性更新它们及其受影响的子依赖——这是最干净、最可控的批量更新方式，不需要插件、通配符或配置文件。
为什么composer update foo/bar baz/qux能生效，而composer update "foo/*"会失败
Composer 命令行解析器把空格分隔的每个字符串当作一个独立的包名，只要这些包名完整、大小写准确、且已出现在 composer.json 的 require 或 require-dev 中，就会被识别并纳入本次更新范围。它不支持 glob 语法（如 monolog/*），也不接受引号包裹的多包列表（引号会让 shell 把整个字符串当做一个参数传给 Composer）。
- 正确：
composer update monolog/monolog guzzlehttp/guzzle symfony/console - 错误：
composer update "monolog/monolog guzzlehttp/guzzle"（引号导致只传一个参数） - 错误：
composer update monolog/*（Composer 不识别通配符） - 报错提示示例：
Package monolog/monolog is not required in your composer.json，说明该包没在composer.json里显式声明
composer update 多包时，子依赖到底怎么更新
默认行为只更新所列包本身 + 它们直系依赖中「被版本约束影响」的部分，不会触碰其他分支的依赖。比如同时更新 guzzlehttp/guzzle 和 symfony/http-foundation，Composer 会重算这两棵子树的兼容版本，但 monolog/monolog 及其依赖保持不动。
- 若想连带整个依赖树（比如某包升级后要求子依赖也必须升主版本），得加
--with-all-dependencies - 若只想升直系依赖（更保守），用
--with-dependencies - 不加任何 flag 时，子依赖可能卡在旧版，导致运行时报错（如
Class not found），别以为“包更新了就万事大吉” - 升级后务必执行
composer dump-autoload -o，否则新类可能加载失败
怎么安全地升到特定主版本（比如从 ^2.0 到 ^3.0）
不能靠默认 composer update vendor/name 实现主版本跃迁，因为它的版本约束写死在 composer.json 里。必须显式覆盖约束，让 Composer 重新求解。
- 临时指定：
composer update monolog/monolog:^3.0（注意冒号不能漏） - 先改
composer.json："monolog/monolog": "^3.0"，再运行composer update monolog/monolog - 升级失败时，用
composer why-not monolog/monolog:3.0查哪个包在阻拦，常见原因是其他依赖硬锁了psr/log或php版本 - 升完立刻
git diff composer.lock，确认变更仅限预期范围；别跳过这步，lock 文件里多出几十行新增 hash 很可能是意外连带升级
真正容易被忽略的是：多包更新后，composer.lock 的变更粒度比单包更难肉眼判断，尤其当几个包共享同一底层依赖（如都用 psr/cache）时，一个小版本 bump 可能引发连锁反应。每次操作前，先 composer outdated --direct 看清目标，比凭经验列包名靠谱得多。
