Composer 的 @dev、@alpha、@beta 是显式覆盖包稳定性策略的版本修饰符：@dev 强制拉取开发分支最新提交；@alpha 仅接受 -alpha 后缀版本；@beta 接受 -beta 和 -alpha 版本；@RC 必须全大写才生效；@stable 强制只装稳定版。
Composer 的 @dev、@alpha、@beta 是什么？
它们是 Composer 用来显式覆盖包稳定性策略的「版本修饰符」，不是版本号本身，而是附加在包名或约束后的标签，告诉 Composer：“哪怕它不稳，我也要这个版本”。
-
@dev：强制走开发分支（如dev-main、dev-develop），拉取最新提交，不看 tag -
@alpha：只接受带-alpha后缀的版本，跳过dev-分支和-beta -
@beta：接受-beta和-alpha（Composer 自动向下兼容） -
@RC：必须全大写，接受-RC1、-rc1会被忽略 → 退回到默认stable行为 -
@stable：等价于不加任何 flag，只认无后缀或带-stable的正式发布版
常见错误现象：composer require vendor/pkg:2.0.0-beta1 报错“could not find package”，其实是没配 minimum-stability，或者误写成 @rc1（小写）被直接无视。
怎么让 Composer 允许装 beta 版本？
不能只靠 require 里写 @beta，得先打开项目级“许可闸门”：
- 在
composer.json中设置"minimum-stability": "beta" - 或临时命令行安装：
composer require vendor/pkg:@beta --stability=beta（但推荐改配置）
注意：
-
minimum-stability是全局门槛，值越低（如dev）越宽松，越容易拉到不稳定代码 - 它只对未显式指定 stability flag 的依赖生效；一旦你写了
vendor/pkg:dev-main，哪怕minimum-stability是stable，照样装 - 某些包自己的
composer.json声明了"minimum-stability": "dev"，会覆盖你项目的设置，子依赖仍可能拉dev版
prefer-stable 是不是“保险开关”？
不是。它是“偏好开关”，不是“拦截开关”。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
"prefer-stable": true的作用是：当多个候选版本都满足minimum-stability时，优先挑更稳定的那个（比如有1.2.0和1.2.0-RC2，就选前者） - 它完全不阻止你显式 require
@dev或@beta - 单独设
prefer-stable而不设minimum-stability，基本没效果；真正限制安装范围的，还是后者
典型误用场景：
想只用稳定版，却只加了 "prefer-stable": true，结果依赖里写了 "some/pkg": "3.0.0-RC1"，Composer 照装不误——因为 RC 满足默认 minimum-stability: stable（RC 属于 stable 级别）。
RC 必须大写、@stable 不等于“没 flag”？
必须大写，是 Composer 解析器的硬规则：@RC ✅，@rc ❌，@Rc ❌。小写会被整个忽略，降级为按默认 stable 解析，导致找不到包。
@stable 看似多余，但它有明确语义：强制 Composer 只考虑标记为 stable 的版本，哪怕 minimum-stability 是 beta，也能局部收紧。例如：
"require": {
"vendor/pkg": "2.0.0@stable"
}
此时即使项目允许 beta，这个包也只会装 2.0.0（不含后缀）或 2.0.0-stable，不会退到 2.0.0-beta2。
最易被忽略的一点：稳定性标记的解析发生在依赖图展开阶段，而包自身声明的 minimum-stability 会污染子依赖链——你改了自己项目的设置，不一定管得住第三方包引的第三方包。
