正确做法是运行 composer update vendor/name（如 composer update monolog/monolog），它会严格遵循 composer.json 中该包的版本约束进行更新，必要时需手动调整版本号并确保 composer.lock 同步。

composer update 只更新一个包，不是加 --only

Composer 没有 --only 这种参数，加了会报错 Unrecognized option "--only"。想单独更新某个包，得靠指定包名本身——不是“排除其他”，而是“只提这个”。

常见错误是写成 composer update --dry-run 看效果，结果发现没锁版本，顺手把一堆依赖全升了；或者误以为 composer require vendor/name 能升级，其实它只在没安装时才装，已存在且满足约束时直接跳过。

• 正确做法：运行 composer update vendor/name（例如 composer update monolog/monolog）
• 它会尊重 composer.json 中该包的版本约束（比如 "monolog/monolog": "^2.8"），只在这个范围内找最新版
• 如果想强制升级到某个具体版本，先改 composer.json 里的版本号，再跑 composer update vendor/name
• 加 --with-dependencies 会连带更新它的直接依赖（谨慎用，可能引发连锁升级）

更新失败时先看 lock 文件和版本约束冲突

执行 composer update vendor/name 报错，十有八九不是命令写错了，而是版本解不开。Composer 不是“下载最新版”，而是在整个依赖图里找一组能共存的版本。

典型现象：Root composer.json requires vendor/name ^3.0, found vendor/name[dev-main, 4.0.x-dev] but these were not loaded —— 说明你写的约束太窄，新版本根本进不来。

Workflow Decomposer

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

下载

• 先检查 composer.json 里该包的版本字符串，是否写死了 "1.2.3" 或用了 ~1.0 这类窄范围
• 用 composer show vendor/name 看当前装的是哪个版本、有哪些可选版本
• 临时放宽约束（比如从 "^1.2" 改成 "^1.0 || ^2.0"），再试 composer update vendor/name
• 别忽略 composer.lock：如果它锁着旧版本，而 composer.json 又没改，update 实际不会动

require --update-with-dependencies 和 update 的区别

composer require vendor/name:version --update-with-dependencies 看起来像升级，但它本质是“假装重新装一遍”，行为和 update 不同。

它会尝试把目标包及其所有子依赖都升到满足新约束的最新版，容易突破原有兼容边界。而 composer update vendor/name 默认只更新该包及其直系依赖（不递归），更可控。

• 用 require --update-with-dependencies 前，先 git diff composer.json 确认你真想改约束
• 它会自动修改 composer.json，如果你只是想试升级，不如手动改完再 update
• 如果项目里有 platform 配置（比如 "php": "8.1"），require --update-with-dependencies 可能无视它去拉不兼容的包，update 则更守规矩

CI/CD 里更新单个包要小心缓存和 lock 文件

在 GitHub Actions 或 GitLab CI 里跑 composer update vendor/name，常遇到“明明改了 composer.json 却没生效”，其实是缓存或工作流顺序问题。

• 确保 composer install 前没有 composer.lock 缓存污染——有些流程会缓存整个 vendor/，导致 update 根本不触发
• 如果 CI 是基于 composer.lock 安装的，那 update 必须生成新 lock 才有效；记得把新 composer.lock 提交回去，否则下次 CI 还是旧版
• 避免在 CI 里用 --no-interaction --no-ansi 以外的选项，像 --dry-run 在 CI 里看不到输出，等于白跑

更新单个包这事，表面是敲一行命令，实际卡点都在版本约束和 lock 文件的咬合关系上。很多人盯着命令语法，却忘了先 cat composer.json 和 cat composer.lock | head -20 对一眼。