prefer-stable 和 minimum-stability 共同控制 Composer 依赖安装：minimum-stability 设定全局最低稳定性（如 beta），prefer-stable 在满足条件下优先选更稳定版本；可通过 @ 指定包级稳定性，建议生产环境设 stable 并个别放宽。
当使用 Composer 管理 PHP 项目依赖时，prefer-stable 和 minimum-stability 是两个关键配置项，它们共同决定哪些版本的包可以被安装。理解它们的交互方式，有助于避免依赖冲突或意外安装不稳定的版本。
minimum-stability 控制默认匹配级别
该配置指定项目允许安装的最低稳定性。可选值包括：dev、alpha、beta、RC、stable（按稳定性升序排列）。
- 设置为
"minimum-stability": "beta"，Composer 可以安装 beta、RC 和 stable 版本。 - 若所有依赖都没有明确指定版本，Composer 会从符合此稳定性的版本中选择。
- 这个设置是全局的，影响所有未单独指定稳定性的依赖。
prefer-stable 倾向于选择更稳定的版本
当 prefer-stable 设为 true，即使 minimum-stability 允许 dev 或 beta 版本，Composer 也会在可能的情况下选择更稳定的版本（如 stable）。
- 例如：某个包有 v1.0.0（stable）和 v2.0.0-beta.1（beta），如果
prefer-stable: true，即使 minimum-stability 是 beta，Composer 仍优先选择 v1.0.0。 - 它不影响“能否安装”，只影响“优先选择哪个”。
利用版本约束覆盖全局规则
可以通过在 require 中显式指定带稳定性的版本约束，来覆盖全局设置。
- 例如：
"symfony/http-foundation": "^5.4@beta"明确允许 beta 版本。 - 或者：
"monolog/monolog": "^2.0@stable"强制只选 stable 版本，即使 minimum-stability 更宽松。 - 这种写法比依赖全局配置更精确，适合关键依赖。
常见问题与解决建议
实际使用中，这两个配置可能导致看似矛盾的结果：
-
问题1：明明有 stable 版本，却装了 dev 分支？
→ 检查是否某个依赖强制要求 dev 版本，或锁定了特定分支。可用composer why-not vendor/package stable-version查看原因。 -
问题2：想用一个 beta 包，但无法安装？
→ 确保 minimum-stability 至少为 beta，或使用@beta后缀。 -
建议：生产项目推荐设置
"minimum-stability": "stable"并配合"prefer-stable": true，仅对特定包通过 @ 标记放宽限制。
基本上就这些。合理搭配这两个配置，加上精准的版本约束，就能在灵活性与稳定性之间取得平衡。
