直接运行 composer update vendor/package-name 是唯一可靠方式，它严格限定作用域，仅重新求解目标包及其直系依赖，按 composer.json 约束拉取最新兼容版并更新 composer.lock。
直接运行 composer update vendor/package-name 就是强制更新单个包的唯一可靠指令，不需要加任何 flag，也不支持命令行指定版本号。
为什么 composer update vendor/package-name 才算“强制”
这里的“强制”，不是指跳过约束或硬覆盖版本，而是指明确限定作用域：Composer 会忽略其他所有顶层包，只重新求解目标包及其直系依赖的版本组合。它不看当前 vendor 里装了什么，只按 composer.json 中该包的约束（如 "^2.8"）去拉取满足条件的最新可用版，并写入 composer.lock 对应条目。
常见误操作包括：
- 输成
composer update package-name（漏掉vendor/）→ 报错Package "package-name" not found - 输成
composer update "monolog/monolog"（带引号）→ shell 可能吞掉斜杠，实际执行的是composer update全量更新 - 加
--only或--with-dependencies→ 这些参数根本不存在，会报[InvalidArgumentException] Unknown option
composer update 没反应？先查这三件事
表面执行成功但 vendor/ 和 composer.lock 都没变，大概率不是命令错了，而是约束锁死了：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查
composer.json中该包的版本字段是否为完全固定值，比如"monolog/monolog": "2.8.0"或"1.2.3"—— 这种写法下，update不会动它 - 运行
composer show monolog/monolog看已安装版本，再跑composer show -a monolog/monolog查所有可用版本，确认有没有更高版可选 - 如果想升到约束外的版本（如从
^2.8升到^3.0），必须先手动改composer.json，再执行composer update monolog/monolog（仍要带包名）
真要“跨约束升级”，两步不能少
Composer 不允许命令行直接指定版本更新（composer update monolog/monolog:3.0.0 是无效语法）。必须分步操作：
- 手动编辑
composer.json，把对应包的版本改成目标值，例如："monolog/monolog": "^3.0" - 再运行
composer update monolog/monolog（注意：不是composer update） - 如果改完还卡在旧版，检查
composer.lock是否残留旧约束 —— 可删掉composer.lock和vendor/后重试（仅限本地环境）
最常被忽略的一点：更新后别只盯着终端输出，一定要 git diff composer.lock 确认只有目标包的 version、source、dist 字段变化。哪怕只多一个 psr/log 的变动，都说明它的新版本有隐式依赖推动，得提前验证代码兼容性。
