minimum-stability 是 Composer 的版本准入门槛，非优先级选项；默认值 stable 仅允许 stable 版本，排除 alpha/beta/RC/dev 等；设为 beta 则允许 alpha、beta、RC 和 stable 版本。
设置 minimum-stability 会告诉 Composer：**只允许安装等于或高于该稳定度的包版本**。它不是“优先选”，而是“准入门槛”——低于这个级别的版本，即使存在、即使满足版本约束，也会被直接排除在候选列表之外。
stable 是默认值，也是最保守的选择
当你没显式设置时，Composer 默认使用 "minimum-stability": "stable"。这意味着：
- 只会考虑带有
-stable后缀（或无后缀）的版本，比如2.5.0、3.0.0-stable； -
2.5.0-rc1、2.5.0-beta2、dev-main全部被跳过； - 即使你的
require写的是"vendor/pkg": "^2.5"，而只有2.5.0-rc1可用，Composer 也会报错“找不到匹配的稳定版本”。
降低 stability 会让更多预发布版进入解析范围
设为 "beta"，Composer 就会接受 alpha、beta、RC 和 stable 版本（按稳定性从低到高：alpha
-
"minimum-stability": "beta"→ 允许1.0.0-alpha、1.0.0-beta，但拒绝dev-develop； -
"minimum-stability": "RC"→ 允许1.0.0-rc1，但拒绝1.0.0-beta3； -
"minimum-stability": "dev"→ 所有版本都可选，包括dev-main、dev-feature/x。
per-package 的 stability override 更灵活
全局 minimum-stability 是兜底规则，你可以对单个包单独放宽限制：
- 在
require中写"vendor/pkg": "dev-main as 1.0.0"，就明确允许 dev 分支； - 或者加
"prefer-stable": true配合minimum-stability: dev，让 Composer 在满足约束的前提下，优先选 stable 版本（而非强制只用 stable）； - 注意：
"@dev"这类版本别名只在require中有效，不能用于minimum-stability值。
依赖链中所有包都受同一规则约束
minimum-stability 是项目级策略，影响整个依赖图谱：
- 你自己的
composer.json设为beta，那么你直接 require 的包，以及这些包所依赖的子依赖，全都必须 ≥ beta； - 如果 A 包要求
B:^2.0，而 B 的最新 stable 是1.9.0，但2.0.0-beta1已发布——只要你的minimum-stability≥ beta，B 就能装上2.0.0-beta1； - 反之，若 A 包内部
require了C:dev-main，而你设了minimum-stability: stable，Composer 会拒绝安装 A，因为它的依赖 C 不达标。
基本上就这些。它不复杂，但容易忽略——尤其当某个依赖突然装不上时，先看一眼 stability 设置和可用版本列表，往往比翻半天报错日志更快。
