最常用、最可控的批量更新方式是composer update后空格分隔多个已声明在composer.json中的包名，如composer update monolog/monolog guzzlehttp/guzzle，仅更新这些包及其受影响子依赖，不改动其他依赖，升级后须检查composer.lock变更并运行全量测试。
不能“一键批量更新所有依赖”而不承担风险——真正安全的批量更新，必须明确指定包名、控制升级范围，并始终以 composer.lock 变更为核心观测点。
怎么只更新几个指定包（最常用、最可控）
直接在命令后列出包名，Composer 就只动这几个，连带它们受影响的子依赖，其他一概不动。这是日常维护中推荐的默认方式。
-
composer update monolog/monolog guzzlehttp/guzzle symfony/console—— 包名之间空格分隔，不加引号、不用通配符 - 若某个包未在
composer.json的require或require-dev中声明，会报错：Package xxx is not required in your composer.json - 想升到特定主版本？临时加约束：
composer update monolog/monolog:^3.0（注意冒号不能漏） - 升级后务必检查
git diff composer.lock，确认变更范围是否符合预期
怎么让指定包连带整个依赖树一起更新
单靠 composer update vendor/name 只更新该包本身，它的子依赖可能还卡在旧版，导致运行时兼容问题。这时得用 --with-all-dependencies。
-
composer update laravel/framework --with-all-dependencies—— 这会重算 Laravel 及其全部子依赖（如symfony/http-foundation、nesbot/carbon等），但不会碰phpunit或doctrine/dbal这类无关包 - 它仍受
composer.json中版本约束限制：若写的是"^9.0"，就不会升到 v10 - 性能代价明显：依赖越深、约束越复杂，SAT 求解耗时越长，比普通 update 慢数倍
- 别和
--with-dependencies混淆：后者只升直系子依赖，前者是整棵子树穿透
怎么发现哪些包其实该批量更新了
凭记忆列包名容易漏掉安全更新或关键小版本。先跑 composer outdated，再决策，比盲目 update 更可靠。
-
composer outdated --direct—— 只看你自己显式 require 的包，优先处理这些 - 输出里带
!的行，表示 Packagist 标记为有安全公告，这类建议立即加入批量更新列表 -
composer outdated --minor-only—— 过滤掉主版本跃迁，适合只想做保守更新的场景 - 注意：
latest列只是 Packagist 当前稳定版，不一定兼容你的 PHP 版本或已有依赖
为什么不能用通配符（比如 monolog/*）
Composer 原生不解析 * 或 vendor/* 这类 glob 模式。你敲 composer update monolog/*，它会直接报错：Could not find package monolog/*，不是找不到包，是压根不认这个语法。
- 真要按前缀批量操作，可用 shell 组合：
composer show --name-only | grep '^monolog/' | xargs -r composer update - Windows（非 Git Bash）上
xargs行为不一致，Mac 需装findutils才支持-r - 更稳的做法仍是手动列名——CI 流程里可复现、Git 提交记录清晰、回滚路径明确
最容易被忽略的一点：每次 composer update 都是重新决策整个依赖图，composer.lock 一旦提交，就影响所有人。升级框架主版本（如 Laravel 9→10）必须手动改 composer.json 中的约束，再配合官方迁移文档验证，指望命令自动完成等于埋雷。
