Composer中版本范围需用双引号包裹含<、>等shell特殊字符的表达式，否则会被shell误解析；^1.2.3等价>=1.2.3 <2.0.0，~1.2.3等价>=1.2.3 <1.3.0，而>=1.2.3无上界；预发布版需显式加@beta或设minimum-stability。
Composer 支持用 >=、<=、>、< 等操作符写版本范围，但直接写 >=1.2.3 是合法的，而 >=1.2.3 <2.0.0 这种组合必须用引号包裹，否则 shell 会把 < 当成重定向符号吃掉。
为什么 composer require foo/bar ">=1.2.3 必须加双引号
不加引号时，终端会把 解释为输出重定向，导致命令实际执行的是 <code>composer require foo/bar ">=1.2.3"，然后尝试把当前目录下名为 2.0.0 的文件内容喂给 composer——这通常报错或静默失败。
常见错误现象：
- 报错：
bash: 2.0.0: No such file or directory - 没报错但只装了
>=1.2.3部分，<2.0.0被忽略 -
composer.json里最终写入的版本约束缺了上限
实操建议：
- 所有含空格或 shell 特殊字符（
<、>、|、&）的版本字符串，一律用双引号包住 - 别依赖单引号——Windows cmd 不认单引号，跨平台项目务必用双引号
- 写完运行后，立刻检查
composer.json中对应包的version字段是否符合预期
^、~ 和 >= 的行为差异很关键
^1.2.3 等价于 >=1.2.3 <2.0.0（不升级主版本），而 ~1.2.3 等价于 >=1.2.3 <1.3.0（不升级次版本）。但 >=1.2.3 本身没有上界，会匹配 1.2.4、2.0.0、3.1.0 ——只要满足“大于等于”就合法。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
使用场景：
- 需要严格锁定次版本内更新（如插件兼容性敏感），优先用
~1.2.3 - 要允许主版本升级但需人工确认（比如已测试过 v2 API），才用
>=1.2.3+ 手动composer update foo/bar - 想表达“至少 v1.2.3，且绝不能到 v2”，就必须显式写
">=1.2.3 <2.0.0"，不能只靠^（因为^在 v1.x 下等效，但 v0.x 行为不同）
带连字符的预发布版本（如 1.2.3-beta.1）和 >= 的坑
Composer 默认把预发布版本（-alpha、-beta、-rc）视为比正式版低，所以 >=1.2.3 不会匹配 1.2.3-beta.1，但会匹配 1.2.3、1.2.4、1.3.0。
容易踩的坑：
- 误以为
>=1.2.3能拉到最新 beta，结果一直卡在旧 stable 版 - 在
composer.json里写了"1.2.3-beta.1"，但其他依赖要求>=1.2.3，导致冲突无法安装 - CI 环境中因未设
"minimum-stability": "beta"，>=范围自动过滤掉所有预发布版
实操建议：
- 要包含预发布版，必须显式声明稳定性：
"foo/bar": ">=1.2.3@beta"或全局设"minimum-stability": "beta" - 上线前务必删掉
@beta类标记，避免生产环境意外拉到不稳定版本
最常被忽略的一点：版本范围是交给 Composer 的 VersionParser 解析的，不是正则也不是简单字符串比较。比如 >=1.2 会被补全为 >=1.2.0，而 >=1.2.0.0 会报错——它不接受四位版本号。写之前最好跑一遍 composer show foo/bar --all 看清真实发布的版本格式。
