minimum-stability 合法值为 dev、alpha、beta、rc、stable（大小写不敏感），按稳定性从低到高排列；它作为 composer.json 顶级字段，控制未显式指定稳定性的依赖可安装的最低稳定性级别。
minimum-stability 是 Composer 用来控制「允许安装哪些稳定性级别的包」的全局开关。它不决定某个包本身是否稳定，而是像一道过滤器：只有稳定性 ≥ 当前设置的包，才被允许安装或更新。
minimum-stability 的合法值有哪些
合法值只有五个，按稳定性从低到高排列：dev、alpha、beta、RC（即 rc）、stable。注意大小写不敏感，但推荐小写。
-
dev：允许安装带-dev后缀的开发分支（如dev-main、dev-feature/x） -
alpha/beta/RC：对应语义化版本中的预发布标记，例如1.0.0-alpha.1、2.3.0-rc.2 -
stable：仅接受无任何稳定性后缀的版本，即形如1.2.3、2.0.0的正式发布版
怎么在 composer.json 中设置 minimum-stability
它必须作为顶级字段写在 composer.json 中，不能嵌套。常见写法：
{
"minimum-stability": "stable",
"prefer-stable": true
}
注意两点：
- 该配置只对「未显式指定稳定性」的依赖生效。比如你写
"monolog/monolog": "^2.0"，Composer 才会按minimum-stability去筛选可用版本；但如果你写"monolog/monolog": "dev-main"，那就直接装dev-main，完全绕过该限制 - 它不是「强制降级」——设成
stable不会让已安装的alpha包自动卸载，只影响后续require或update行为
prefer-stable 是什么？和 minimum-stability 什么关系
prefer-stable 是个布尔开关，默认 false。当它为 true 时，Composer 会在满足 minimum-stability 前提下，优先选择更稳定的版本。
举例：当前 minimum-stability 是 beta，而某包有 2.0.0-beta.3 和 2.0.0 两个可选版本：
- 若
prefer-stable: false：可能装beta.3（只要满足最低要求） - 若
prefer-stable: true：会选2.0.0（更稳定，且仍 ≥beta）
所以生产环境建议同时设两者："minimum-stability": "stable" + "prefer-stable": true，避免意外引入非稳定依赖。
常见错误：为什么设了 stable 还装了 dev 包
最常见原因是依赖链中某个包在 require 里写了显式不稳定版本，比如：
"some/package": "dev-master"
此时 minimum-stability 完全不生效。检查方式：
- 运行
composer show some/package看实际安装的版本号 - 用
composer depends some/package找出是谁引入了它 - 特别注意
repositories自定义源或path类型仓库，它们常绕过稳定性检查
真正难排查的是间接依赖——某个你没直接 require 的包，在它自己的 composer.json 里写了 "foo/bar": "dev-main"，那它的下游使用者也会被拖入不稳定状态。
