Composer 默认只装 @stable 版本，@dev/@beta/@RC 需显式“开闸”；minimum-stability 是硬过滤器，决定候选版本池，prefer-stable 仅影响池内排序；@beta 兼容 @alpha 但不接受 @dev；dev-main 等非语义化版本生产环境慎用。
Composer 默认只装 @stable 版本，其他如 @dev、@beta、@RC 都是显式“开闸”行为——不加配置或写错格式，它就当没看见。
为什么 composer require vendor/pkg:1.2.0@beta 有时不生效？
根本原因不是命令写错了，而是 minimum-stability 全局门槛卡死了候选池。比如你项目设了 "minimum-stability": "stable"（默认值），那哪怕你写了 @beta，Composer 也会先过滤掉所有 beta 及以下版本，再去看约束是否匹配——此时 @beta 根本进不了比对环节。
- 确认真实发布记录：
composer show vendor/pkg --all，看它是否真打了1.2.0-beta1这样的 tag，而不是只有dev-main或1.2.0-rc1 -
@RC必须全大写；@rc或@Rc会被忽略，退回到@stable行为 -
@beta自动向下兼容@alpha，但不会接受@dev分支（如dev-main）
minimum-stability 和 prefer-stable 到底谁管什么？
minimum-stability 是硬过滤器，决定哪些版本能进候选池；prefer-stable 是池内排序策略，只在多个满足条件的版本共存时起作用。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 设
"minimum-stability": "beta"→ 池里只有beta、RC、stable版本；alpha和dev直接消失 - 设
"prefer-stable": true且池中有2.1.0@stable和2.2.0@beta→ Composer 选前者，哪怕后者版本号更高 - 二者必须配合使用才有意义：
prefer-stable单独开启，对minimum-stability: stable项目毫无影响
临时装一个 dev 分支该用哪种写法？
别碰 --stability=dev，它会临时放宽全局门槛，可能顺手把其他依赖也拖进不稳定版本。精准做法是用 @dev 后缀直接授权单个包。
-
composer require vendor/pkg:dev-main—— 拉最新main分支快照，每次update都可能变 -
composer require vendor/pkg:dev-develop@dev—— 显式声明接受dev-develop分支，避免被minimum-stability拦截 -
composer require vendor/pkg:3.1.0-dev@dev—— 如果作者打了这个 tag，也能命中 -
dev-main不是版本号，不走语义化版本逻辑，生产环境慎用
真正容易被忽略的是：稳定性等级是严格排序的硬规则（dev ），不是“建议”或“倾向”。你设了 beta，Composer 就真的会把 alpha 当不存在——哪怕它是唯一满足 ^2.0 约束的版本。
