minimum-stability 是 composer.json 中控制依赖包默认稳定性级别的全局开关，它决定未显式指定版本约束时的匹配门槛；设为 dev 会导致所有未锁定版本的依赖可能被替换为不稳定开发快照，引发线上行为不可控。
minimum-stability 是什么，为什么不能随便设成 dev
minimum-stability 是 composer.json 中控制依赖包默认“稳定性级别”的全局开关。它不是“允许安装哪些包”，而是“当没显式指定版本约束时，默认按什么稳定程度去匹配”。比如你写 "monolog/monolog": "^2.0"，Composer 会优先找 stable（即正式版）的 2.x 版本；但如果所有匹配版本都只有 beta 或 dev-master，而你的 minimum-stability 是 stable，那就会报错——不是包不存在，是“不符合稳定性门槛”。
设成 dev 看似能解决安装失败，但后果是：所有未锁死具体 commit 或版本号的依赖，都可能被 Composer 自动拉下未测试、随时会变的开发快照，项目上线后行为不可控。
常见 stability 值及对应行为
合法值有：stable、RC、beta、alpha、dev，按从高到低排序。注意大小写敏感，必须小写（如 "minimum-stability": "stable"）。
-
stable：只接受带正式版本号（如1.2.3）且无任何后缀的包 -
RC：允许1.2.3-RC1、2.0.0-rc这类候选发布版 -
beta：再放宽到1.2.0-beta1 -
alpha：包含-alpha、-a后缀的早期版本 -
dev：连dev-main、dev-develop都算合法——这是最危险的默认值
实际项目中，95% 的线上应用应坚持 "minimum-stability": "stable"，仅对个别确需尝鲜的包用 "@dev" 显式覆盖。
如何为单个包绕过 minimum-stability 限制
全局设为 stable 时，若某个包确实只有 beta 版可用（比如新 major 版尚未发正式版），不要调低全局设置，而是用 @ 语法在 require 中单独声明：
{
"minimum-stability": "stable",
"require": {
"symfony/console": "^6.4",
"laravel/sanctum": "3.3.3 as 3.3.0",
"spatie/laravel-ray": "1.34.0@beta"
}
}
关键点：
-
"spatie/laravel-ray": "1.34.0@beta"中的@beta显式告诉 Composer：这个包允许取 beta 级别版本，哪怕全局是 stable -
as别名用于解决版本号不一致问题（例如包实际 tag 是v1.34.0-beta，但你想让它被当作1.34.0处理） - 执行
composer update spatie/laravel-ray时，Composer 会只对该包放宽限制，其余仍受minimum-stability约束
require-dev 和 minimum-stability 的关系
require-dev 中的包**同样受 minimum-stability 约束**。开发时想装 phpunit/phpunit 的 dev-main？不能只改 minimum-stability，否则生产依赖也会失控。正确做法是：
- 保持
minimum-stability为stable - 在
require-dev中写明"phpunit/phpunit": "^10.5@dev" - 或更稳妥地，用
prefer-stable: true配合@dev（见下条）
顺带一提："prefer-stable": true 是个实用配置——它让 Composer 在满足约束前提下，优先选 stable 版而非同版本下的 RC/beta。它不改变 minimum-stability 的硬性门槛，只是影响“同版本多稳定性可选时”的决策倾向。
真正容易被忽略的是：即使你写了 @dev，Composer 仍会检查该 dev 分支是否满足 minimum-stability 所定义的最低等级。比如 minimum-stability 是 beta，你就不能用 @alpha；如果真需要 alpha，必须把全局值设为 alpha 或更低——这恰恰说明，随意调低 minimum-stability 实际上是在为所有依赖开后门。
