最常用、最可控的批量更新方式是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。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 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 中的约束，再配合官方迁移文档验证，指望命令自动完成等于埋雷。