Composer不支持npm风格的版本范围（如1.2.x、>=1.2.0），其版本约束基于语义化版本规则，仅识别^、~、=等特定符号，且^1.2.3等价于>=1.2.3 =1.2.3
Composer 不支持 npm 风格的版本范围（比如 1.2.x、>=1.2.0 这类写法），它只认自己的 SemVer 约束语法——用错符号，轻则装错版本，重则锁死或跳过安装。
composer.json 里写的 ~ 和 ^ 到底对应什么范围
它们不是“大概兼容”，而是有明确定义的数学区间，且解析逻辑和 npm 完全不同：
-
^1.2.3等价于>=1.2.3 ：主版本锁定，允许小版本和补丁升级 -
~1.2.3等价于>=1.2.3 ：次版本锁定，只允许补丁升级 -
~1.2等价于>=1.2.0 （注意：没写补丁位时自动补 <code>.0） -
^0.5.0实际等价于~0.5.0（主版本为 0 时，^只放开最右一位）
为什么写 "monolog/monolog": "~1.2.3" 可能装不上
常见错误现象是 composer install 报 No matching package found，不是你网络问题，而是语义匹配失败：
- 该包最新 tag 是
1.2.2或1.3.0，都不在>=1.2.3 范围内 - 你写了
~1.2.3，但包作者根本没打v1.2.3这个 tag（只打了v1.2.3-RC1） - 你的
minimum-stability是stable，而1.2.3实际是beta标签，被直接过滤
查可用版本最准的方式是：composer show -a monolog/monolog，别靠猜。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
想精确锁定一个版本，就别用符号
如果你要的是确定性，不是“将来可能升级”，那所有约束符都是干扰项：
- 写
"monolog/monolog": "1.2.3"（不带任何符号）→ 只装这个 tag，不会漂移 - 写
"monolog/monolog": "^1.2.3"→ 下次composer update可能升到1.9.9，哪怕你没动代码 - 写
"monolog/monolog": "dev-main"→ 拉的是分支最新 commit，不是稳定版，source.type在composer.lock里会是source而非dist
CI/CD 中应优先用无符号写法 + 提交 composer.lock，而不是依赖 ^ 做“自动兼容”——兼容性得靠测试验证，不是靠符号许愿。
composer require 命令里的版本写法必须带冒号
这是最容易手抖出错的地方：命令行里版本不是可选项，是必需参数，且格式极其严格：
-
composer require monolog/monolog:1.2.3✅ 正确，精确安装并写入composer.json -
composer require monolog/monolog@1.2.3❌ 报Could not find a matching version -
composer require monolog/monolog=1.2.3❌ 同样报错，=不是合法分隔符 -
composer require monolog/monolog:"1.2.3"✅ 加引号可防 shell 解析异常（尤其含-时）
装完务必检查 composer.lock 里该包的 version 字段是否真为 "1.2.3"，以及 source.type 是 dist —— 如果是 source 且 reference 是长 commit hash，说明你实际拉的是 dev 分支，不是 tag。
