minimum-stability 是 Composer 的全局稳定性门槛，决定哪些版本可被安装；它允许≥该级别的所有版本，而非仅锁定指定级别，未明确后缀的依赖才受其约束。
minimum-stability 是 Composer 决定“哪些版本算合格”的门槛线——它不指定具体装哪个版本，而是划出一条稳定性下限：低于这条线的包（比如 dev-main、2.0.0-beta3），默认直接被过滤掉，哪怕你 require 的约束语法上完全匹配。
为什么设成 stable 却还是装了 RC 版？
常见误解是“设了 minimum-stability 就能锁死只装 stable”，但实际行为更像“允许 ≥ 该级别的所有版本”。例如：
- 设
"minimum-stability": "stable"→ 只接受无后缀或-stable后缀的版本（如1.2.0、1.2.0-stable）；1.2.0-rc1、1.2.0-beta、dev-main全部被跳过 - 但如果你的某个依赖（比如 A 包）在它的
composer.json里写了"require": {"B": "^2.0"}，而 B 目前最新可用版只有2.0.0-rc1，且你的项目minimum-stability是RC——那么 B 就会被装上，即使你主观只想用 stable - 换句话说：
minimum-stability是全局通行证，不是个人安检仪；它管的是“能不能进”，不管“该不该进”
想用一个新功能，又怕崩，怎么安全放宽？
生产项目不该盲目调低 minimum-stability。真正稳妥的做法是“全局守稳 + 局部放行”：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 保持
"minimum-stability": "stable"和"prefer-stable": true（后者确保有 stable 就不选 RC/beta） - 对那个非用不可的新包，显式加稳定性后缀：
"vendor/pkg": "dev-main as 1.0.0"或"vendor/pkg": "^3.0@beta" - 避免写
"vendor/pkg": "dev-main"这种裸分支引用——它绕过版本约束，下次composer update可能拉到完全不兼容的提交 - 如果该包本身没发 stable 版，但你确认
dev-main当前状态可用，建议用as别名锁定逻辑版本号，便于后续回滚
依赖链里有人偷偷用了 dev 分支，怎么办？
你设了 minimum-stability: stable，但 composer install 报错说 “无法解析 xxx，因为其依赖 yyy 要求 dev-master”——这不是你写的，是上游包自己埋的雷：
- 运行
composer why-not vendor/yyy dev-master查谁在强求不稳定版本 - 检查报错中提到的包（比如 A）的
composer.json，看它是否在require里硬写了"yyy": "dev-master" - 解决方案分三级：① 提 PR 让上游改用稳定版；② 本地 fork 并 patch 它的
composer.json；③ 临时在你项目里用"repositories"指向你 fork 的地址（慎用，增加维护成本） - 别用
"minimum-stability": "dev"来兜底——这等于给整个依赖树开绿灯，可能把其他几十个包全拖进不稳定区
最常被忽略的一点：这个配置影响的是“未明确指定稳定性的依赖”。只要你为某个包写了带 @ 后缀的版本（如 "^2.0@alpha"），minimum-stability 就完全不参与判断——它只管那些你只写了 "^2.0" 的包。所以真正的控制权，永远在你写的每一行 require 里。
