composer require vendor/package:1.2.3是唯一可靠方式，冒号分隔、版本号无v前缀、不加@或=，包名大小写敏感，安装后composer.json中为精确版本字符串且composer.lock一致。
想装哪个版本就是哪个版本，不升级、不漂移，关键就一条：composer require vendor/package:1.2.3 —— 冒号分隔、无符号、无^无~，否则不是“指定”，只是“提示”。
composer require vendor/package:X.Y.Z 是唯一可靠写法
这是命令行下最直接、最不易出错的方式。Composer 会自动把 "vendor/package": "X.Y.Z" 写进 composer.json 的 require 字段，且不加任何语义化修饰符。
- ✅ 正确：
composer require monolog/monolog:2.9.1→ 写入"monolog/monolog": "2.9.1" - ❌ 错误：
composer require monolog/monolog=2.9.1或@2.9.1或^2.9.1—— 前两者被忽略或报错，后者允许升到2.99.9 - 包名大小写敏感：
monolog/monolog对，Monolog/Monolog直接报Could not find package - 版本号别带
v前缀：monolog/monolog:v2.9.1会被当分支dev-v2.9.1处理，大概率失败
为什么改了 composer.json 还是装旧版？
手动编辑 composer.json 只是声明意图，不会触发安装或替换文件。vendor 目录里的代码不会自动更新。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须执行
composer update vendor/package（局部）或composer update（全量）才会真正拉取并覆盖 -
composer install完全无视composer.json里的新版本声明，它只认composer.lock里记录的版本 - 常见误操作：改完
composer.json就跑composer install，结果 vendor 里还是老版本 —— 这是预期行为，不是 bug
装不上？先查清楚是不是版本根本不存在
报 Could not find a matching version，90% 不是命令写错，而是目标版本没发布、被弃用、或稳定性不匹配。
- 运行
composer show monolog/monolog --all，看输出里有没有你要的2.9.1tag - 打开 Packagist 页面，搜
2.9.1，确认是否 listed、stable、未被 abandoned - 如果版本是
RC或beta，默认装不上，得加--stability=RC参数：composer require monolog/monolog:2.9.1-RC1 --stability=RC - PHP 版本不兼容也会失败（比如该版本要求
php: >=8.0，而你本地是7.4），错误通常是Your requirements could not be resolved
生产环境换版本，安全操作三步走
怕连带升级一堆依赖、又怕残留旧代码，就得控制节奏。
- 先清理：
composer remove monolog/monolog（删 vendor + 清composer.json） - 再锁定：
composer require monolog/monolog:2.9.1（写死、不带符号） - 最后验证：
grep -A2 '"monolog/monolog"' composer.json确认是"2.9.1"；cat composer.lock | jq '.packages[] | select(.name=="monolog/monolog") | .version'确认锁文件也对得上
精确版本本身不难，难的是每次操作后都去翻 composer.lock 和实际 vendor 文件 —— 很多人跳过这步，结果上线才发现 autoload 加载的还是旧类。
