minimum-stability 是 composer.json 中控制包版本稳定性下限的全局配置，设为 dev 会令所有未显式指定稳定性的依赖默认拉取开发版，破坏构建稳定性；应坚持 stable，仅对特定包显式声明 dev 版本。
minimum-stability 是什么，为什么不能随便设成 dev
minimum-stability 是 composer.json 中控制包版本选择下限的全局配置。它不决定“能不能装”，而是告诉 Composer：“除非显式指定，否则默认只接受这个稳定性级别及更稳定的版本”。比如设为 "stable"，那 dev-master、beta、rc 都不会被自动选中——哪怕你 require 的包本身只发布了 dev-main，也会报错。
常见错误现象：
Could not find package xxxxx with stability dev或安装时跳过预期的开发版包，回退到老的 stable 版本。
- 合法值包括：
"stable"（默认）、"RC"、"beta"、"alpha"、"dev" - 大小写敏感，必须全大写
"RC"，写成"rc"会解析失败 - 该配置仅影响「未显式标注稳定性」的依赖项；如果
require里写了"monolog/monolog": "dev-main"，它就完全绕过minimum-stability
如何为单个包临时放宽稳定性要求
全局设成 "dev" 很危险：所有依赖（包括你没注意的间接依赖）都可能拉取不稳定快照，CI 构建结果不可复现。更稳妥的做法是只对特定包显式声明稳定性。
例如你想用 laravel/sanctum 的最新开发分支：
{
"require": {
"laravel/sanctum": "dev-master as 3.0.x-dev"
}
}
关键点：
- 版本字符串里带
dev-前缀（如dev-main、dev-develop）即表示启用开发版 - 推荐加上
as xxx别名，避免 Composer 报Invalid version string—— 它需要一个符合语义化版本格式的“伪装版号”来参与依赖解析 - 这种写法优先级高于
minimum-stability，无需改动全局配置
prefer-stable 和 minimum-stability 的配合逻辑
prefer-stable 是布尔开关，和 minimum-stability 协同工作：当多个满足 minimum-stability 的版本共存时，它会让 Composer 倾向选择标记为 stable 的那个。
典型配置组合：
{
"minimum-stability": "RC",
"prefer-stable": true
}
效果是：在 RC、stable 同时存在时选 stable；但若只有 RC 和 beta，仍会选 RC（因为 beta 不满足 minimum-stability 下限）。
-
prefer-stable: true不会降级已锁定的 dev 版本（composer.lock里的记录优先） - 它只在
composer update时起作用，且仅影响“候选版本池”内的排序 - 如果你发现某包始终装不上 RC 版，先检查它的
composer.json是否真发布了"version": "3.2.0-RC1"这类明确标记
实际项目中该设成什么值
生产环境项目应坚持 "minimum-stability": "stable"，这是最安全的基线。任何偏离都需要明确理由和对应措施。
例外场景举例：
- 正在参与某个包的 beta 测试 → 在
require中单独写"vendor/pkg": "2.0.0-beta1" - 内部私有包尚未打 stable tag → 用
"internal/utils": "dev-main as 1.0.x-dev"+ 配置repositories - CI 要验证主干兼容性 → 用
COMPOSER_ROOT_VERSION=dev-main composer install覆盖根包版本，而非调低minimum-stability
最容易被忽略的是：改完 minimum-stability 后忘记运行 composer update --lock 来同步 composer.lock。旧 lock 文件仍按原策略锁定版本，导致配置看似生效实则无效。
