正确命令是 composer update vendor/package-name，必须带 vendor/ 前缀，不加引号、不加开关；它默认仅更新该包及其满足版本约束的子依赖，其他顶层包保持不动。
composer update vendor/package-name 是唯一正解
别写 composer update package-name，漏掉 vendor/ 前缀会静默 fallback 到全量更新；也别加引号，composer update "monolog/monolog" 在某些 shell 下会解析失败。正确命令就是裸写全名：composer update monolog/monolog。
它默认只拉取该包及其满足 composer.json 版本约束的子依赖（比如 "^2.0"），其他顶层包版本完全不动——前提是这些包没被目标包的新依赖树间接“拖动”。
- 包名拼错或大小写不符（如
Monolog/monolog）→ Composer 找不到匹配项，直接执行全量update - 包是通过
require-dev安装的，但没加--dev→ 命令无效果，且不报错 - 想升到
^3.0却卡在2.10.0→ 先检查composer.lock里是否已有更严约束，或被其他包锁死
为什么 symfony/console 还是被升级了？
这不是命令失效，是 Composer 的求解逻辑：如果 monolog/monolog:^3.0 的 composer.json 明确 require "symfony/console": "^6.2"，而你 lock 里是 6.1，那它必须升——否则整个依赖图不合法。
这种连带升级无法用开关禁掉，它是保证一致性所必需的。你能控制的只有起点：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
composer show monolog/monolog查看它的require列表，预判哪些子依赖可能动 - 若不想动
psr/log，就在composer.json里显式固定："psr/log": "^2.0" - 执行前加
--dry-run：composer update monolog/monolog --dry-run，看输出里列了哪些包
--no-update-with-dependencies 能真正锁死子依赖吗？
能，但有前提：Composer 2.2+ 支持，且目标包的所有子依赖当前版本必须已满足其新版本的 require 条件。否则会报 conflict 错误，升级中断。
例如：monolog/monolog:^3.0 require "php": ">=8.1"，而你环境是 PHP 8.2、lock 里 psr/log 是 3.0.0（兼容 8.2），这时加 --no-update-with-dependencies 才有效。
- 它不阻止其他顶层包被间接影响（比如被别的包 require），只禁用目标包主动声明的依赖升级
- 加了这个参数后，如果升级失败，别急着删参数重试——先
composer why-not vendor/dep看冲突根源 - 该参数对
require-dev包同样生效，但需额外加--dev
更新完怎么确认真的只动了那个包？
别信终端输出，看 composer.lock 的 git diff：
- 只应出现
packages或packages-dev下对应包名的version、source、dist字段变化 - 如果一堆无关包的
dist.sha256都变了，大概率是platform.php配置和当前 PHP 版本不一致（比如 lock 里锁的是"8.1"，但本地是8.2） -
composer show vendor/package-name输出的versions行要和composer.lock里一致，且installed显示true
最易忽略的是：命令成功 ≠ 业务可用。API 兼容性破坏往往在运行时才暴露，尤其当包升级跨越主版本（如 guzzlehttp/guzzle:6 → 7）时，必须验证实际调用路径。
