minimum-stability控制Composer依赖的版本稳定性，按dev、alpha、beta、RC、stable从低到高排序，默认仅安装stable版本；设为beta则允许beta及以上版本，结合prefer-stable和@标记可精细控制个别包稳定性，建议生产环境使用stable以确保稳定。
Composer 的 "minimum-stability" 配置项直接影响项目中所有依赖包的版本选择范围。它决定了 Composer 在解析和安装依赖时，可以接受哪些稳定程度的发布版本。
什么是 stability（稳定性）等级？
Composer 定义了五种包的稳定性等级，按从低到高排列如下：
-
dev：开发分支，如
dev-main、dev-develop - alpha：早期测试版本
- beta：中期测试版本
- RC（Release Candidate）：候选发布版本
- stable：稳定版本
默认情况下，Composer 只会安装 stable 稳定版本，除非配置允许更低级别的包。
minimum-stability 如何控制依赖选择
该配置位于 composer.json 中，全局作用于整个项目的依赖树（包括间接依赖）。它的值设置一个“最低可接受”的稳定性级别。
例如：
{
"minimum-stability": "beta"
}
表示 Composer 允许安装 beta、RC、stable 的包，但不会主动选择 alpha 或 dev 版本。
如果某个依赖要求一个 RC 版本的库，而 minimum-stability 是 stable，Composer 就会跳过这个 RC 版本，尝试寻找 stable 替代。若找不到，安装失败。
如何精细控制个别包的稳定性？
使用 "prefer-stable" 和 inline stability flags 可以更灵活地管理。
比如，你希望大多数包保持稳定，但允许某个包使用 beta 版：
{
"minimum-stability": "dev",
"prefer-stable": true,
"require": {
"some/package": "^1.0@beta"
}
}
这里将 minimum-stability 设为 dev 放宽整体限制，但开启 prefer-stable 让其他包优先选稳定版，仅对指定包明确要求 @beta。
对项目的影响与建议
- 设为
stable最安全，适合生产环境 - 设为
dev可能引入大量不稳定依赖，需谨慎 - 修改该值会影响所有依赖的解析结果，可能导致意外升级或冲突
- 团队协作时应明确配置，避免因稳定性差异导致环境不一致
基本上就这些。合理设置 minimum-stability 能在功能获取与系统稳定之间取得平衡。
