composer update vendor/package-name 是唯一正解，因其仅更新指定包及其直系依赖，不触发全量重装或连锁升级，严格遵循 composer.json 中的版本约束。
直接运行 composer update vendor/package-name 就是唯一简便且可靠的写法，不需要加任何参数、引号或开关。 其他所有变体——比如加 --with-dependencies、用 composer require、漏掉 vendor/ 前缀、或者不带包名直接跑 composer update——都会偏离“只更新一个包”的目标，轻则无效，重则引发连锁升级。
为什么 composer update vendor/package-name 是唯一正解
Composer 原生就支持按包名精确触发最小范围更新。它会：
- 只读取
composer.json中该包的版本约束（如"monolog/monolog": "^2.8"），拉取满足此约束的最新兼容版本 - 仅顺带更新该包
composer.json中require字段声明的、且未被其他顶层包锁死的子依赖（例如psr/log） - 完全跳过其他顶层包（如
laravel/framework、guzzlehttp/guzzle），哪怕它们也在composer.json里 - 只修改
composer.lock中对应包及其直系依赖的条目，其余不变
composer update 不带包名会怎样
这是最常踩的坑：敲完 composer update 回车后，vendor/ 里一半包都变了，CI 构建突然失败。
- 它会重新解析整个依赖图，升级所有满足当前约束的包（包括间接依赖），等价于“全量重装”
- 不是网络慢或缓存问题，是命令语义本身如此
- 如果误输成
composer update "monolog/monolog"（带引号），某些 shell 会忽略参数，结果仍是无参执行 - 输错包名（如
composer update monolog）会报Package "monolog" is not required，但若拼写接近已存在包（如大小写错误），可能静默 fallback 到全量更新
常见错误操作与真实后果
这些写法看着像在“精准控制”，实际都违背初衷：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer require monolog/monolog:^3.0：本质是改composer.json+ 全量 install，可能顺带升级php要求、psr/log、甚至symfony/polyfill—— 完全不可控 -
composer update --with-dependencies monolog/monolog：强制连带升级所有子依赖（包括被其他包共用的），大概率把psr/http-message从 1.x 升到 2.x，直接 break 接口 -
composer update monolog/*：不支持通配符，报错退出 -
composer update monolog/monolog:3.0.0：语法非法，Composer 不接受命令行指定具体版本
更新前必须确认的三件事
避免白忙活或线上翻车：
- 先查真实包名：
composer show 'monolog/*'（单引号防 shell 展开），确认输出非空且格式为monolog/monolog - 检查是否在
composer.json的require或require-dev区块中存在；如果只是间接依赖（没出现在composer.json里），update命令无效 - 执行
composer update monolog/monolog --dry-run，看输出里只有预期包出现在Updating行；若出现其他包，说明其新版本有强依赖要求，得提前查composer show monolog/monolog的require字段预判
真正难的不是命令怎么敲，而是理解 Composer 的依赖求解逻辑：它永远优先保证整个依赖图合法，而不是“你想动谁就只动谁”。所以每次更新前看一眼目标包的 require 列表，比背命令重要得多。
