minimum-stability是Composer中控制依赖包最低稳定性的配置项，位于composer.json顶层，可选值按稳定性从低到高为dev、alpha、beta、RC、stable，默认为stable。设为stable时仅安装稳定版，确保项目可靠，适合生产环境；若需使用开发中功能，可调低该值或结合prefer-stable与特定包的@dev后缀实现精细控制，既保证整体稳定性又允许个别包引入不稳定版本。
minimum-stability在Composer里扮演的角色，其实就是一道门槛，它决定了你的项目能引入的第三方包（依赖）的最低“成熟度”或者说“稳定性”等级。简单讲，它帮你过滤掉那些你觉得还不够稳妥、不适合当前项目阶段的包。
解决方案
要设置
minimum-stability，你需要在项目的根目录下的
composer.json文件中添加或修改这个配置项。它通常位于文件的顶层，与
require、
autoload等同级。
{
"name": "your-vendor/your-project",
"description": "A brief description of your project.",
"type": "project",
"require": {
"php": ">=7.4",
"monolog/monolog": "^2.0"
},
"minimum-stability": "stable",
"prefer-stable": true
}在这个例子中，
"minimum-stability": "stable"意味着Composer在解析依赖时，默认只会考虑那些被标记为
stable的包版本。如果你需要更前沿、但可能不够稳定的版本，比如开发中的特性，你就需要调整这个值。
可选的稳定性等级从低到高（也就是从最不稳定到最稳定）依次是：
dev(开发版),
alpha(内测版),
beta(公测版),
RC(发布候选版),
stable(稳定版)。
为什么我们非要管minimum-stability
这档子事？
说实话，刚开始用Composer的时候，我可能都没太注意这个配置。但随着项目越来越复杂，尤其是需要引入一些新特性或者社区贡献的包时，它就变得至关重要了。这玩意儿就像是给你的项目设置了一个“风险偏好”。
默认情况下，
minimum-stability是
stable。这很合理，毕竟谁不想自己的项目跑得稳稳当当呢？
stable意味着这个版本经过了开发者充分的测试，API相对固定，出现重大bug或者破坏性变更的概率很低。这对生产环境的项目来说是黄金标准。
但有时候，我们就是想尝鲜，或者项目本身就处于快速迭代的早期，需要某个库的最新功能，而这个功能可能只在
dev版本里有。这时候，如果你的
minimum-stability还是
stable，Composer就会告诉你：“抱歉，找不到符合你要求的稳定版。” 这时，你就得考虑调整它了。
我的经验是，如果你在做实验性项目、内部工具，或者积极参与某个开源库的开发，那么把
minimum-stability设为
dev会让你省心不少。它能让你第一时间获取到最新的代码，但同时也要做好心理准备，可能会遇到一些未知的bug或者API变更。这是一种取舍，看你更看重速度还是稳定性。
不同的稳定性等级到底意味着什么，对我的项目有啥实际影响？
理解这些等级，能帮助你更好地评估引入依赖的风险。它们不仅仅是标签，更是项目成熟度和API承诺的信号。
Kuwebs企业网站管理系统3.1.5 UTF8
下载
酷纬企业网站管理系统Kuwebs是酷纬信息开发的为企业网站提供解决方案而开发的营销型网站系统。在线留言模块、常见问题模块、友情链接模块。前台采用DIV+CSS，遵循SEO标准。 1.支持中文、英文两种版本，后台可以在不同的环境下编辑中英文。 3.程序和界面分离，提供通用的PHP标准语法字段供前台调用，可以为不同的页面设置不同的风格。 5.支持google地图生成、自定义标题、自定义关键词、自定义描
-
dev
(开发版)：这是最不稳定的等级。它通常指向代码仓库的某个分支，比如master
或main
。你可以想象成，你直接拿到了开发者正在敲的代码。好处是最新、最快，能第一时间体验新功能或bug修复。坏处是，随时可能出现破坏性变更，API可能今天一个样，明天又变了，甚至可能根本无法运行。我一般只在开发某个库本身，或者急需某个未发布功能时，才会考虑它。 -
alpha
(内测版)：比dev
稍好一点，但仍处于非常早期的阶段。通常意味着核心功能已经实现，但可能有很多bug，API也极有可能发生变化。它主要是供内部测试或少数早期用户试用。 -
beta
(公测版)：功能基本完整，但可能还有一些已知的bug，或者性能问题。API可能还会有些微调，但大的结构应该已经确定。这个阶段通常会邀请更广泛的用户进行测试，收集反馈。 -
RC
(Release Candidate，发布候选版)：顾名思义，这是非常接近最终稳定版的版本。功能完整，bug也基本修复，API也应该最终确定。如果没有发现重大问题，它很快就会成为stable
版。 -
stable
(稳定版)：这是最推荐用于生产环境的版本。经过充分测试，bug较少，API稳定，通常只会进行兼容性修复。当你看到一个包有stable
版本时，你可以相对放心地使用它。
对项目的影响就是：你设置的
minimum-stability越低（比如
dev），Composer在寻找依赖时就越“宽容”，能找到的版本选择就越多，但也意味着你引入不稳定代码的风险越大。反之，设为
stable则最安全，但可能会错过一些最新的特性。
如果我大部分项目想用stable
，但又想偶尔用一个dev
包怎么办？
这其实是一个非常常见的场景，也是Composer设计得非常巧妙的地方。你不需要为了一个
dev包就把整个项目的
minimum-stability都调成
dev，那样风险太大了。Composer提供了两种非常实用的机制来解决这个问题：
prefer-stable和针对特定包的稳定性声明。
首先是
prefer-stable。这个配置项通常和
minimum-stability一起出现。
{
"minimum-stability": "dev",
"prefer-stable": true
}当
minimum-stability被设置为
dev时，
prefer-stable: true（这在现代Composer版本中通常是默认行为）会告诉Composer：“嘿，虽然我允许你安装
dev版本，但如果一个包有
stable版本可用，请优先选择
stable的。” 这样，你的项目在绝大多数情况下依然会使用稳定版，只有当某个包压根就没有稳定版，或者你明确要求了
dev版时，才会去安装
dev版。这是一种非常好的折衷方案，既能享受
dev的灵活性，又能保持整体项目的稳定性。
其次，也是更精准的办法，就是针对单个包声明其所需的稳定性。你可以在
require或
require-dev段中，在包的版本号后面加上
@stability后缀。
{
"require": {
"php": ">=7.4",
"monolog/monolog": "^2.0",
"some-vendor/bleeding-edge-package": "1.x-dev", // 或者 "1.x@dev"
"another-vendor/experimental-feature": "dev-main" // 也可以直接指向分支
},
"minimum-stability": "stable",
"prefer-stable": true
}看，即使我的
minimum-stability是
stable，我依然可以明确告诉Composer：“对于
some-vendor/bleeding-edge-package，我就是要它的
dev版本。” Composer会尊重这个显式声明，并尝试安装该包的
dev版本，而其他未特殊指定的包则依然会遵循
minimum-stability的
stable规则。
这种粒度级别的控制，让我能在一个项目中灵活地管理依赖的稳定性。我可以让核心框架和重要的业务逻辑库保持
stable，而对于一些辅助性、非关键性的工具或者我正在积极贡献的库，则可以大胆地使用
dev版本。这让我的开发流程既安全又高效，不会因为一个尝鲜的需求而把整个项目都置于不确定的风险之中。
