Composer 的 minimum-stability 设置（stable, RC, beta, alpha, dev）如何影响依赖解析？

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 是兜底规则，你可以对单个包单独放宽限制：

Anakin

一站式 AI 应用聚合平台，无代码的AI应用程序构建器

317

查看详情

• 在 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 设置和可用版本列表，往往比翻半天报错日志更快。