设为 beta 后 Composer 仅对显式声明 @beta 的包或无稳定版的包启用 beta 版本，不会自动降级所有依赖；需配合 @beta 约束使用，且建议同时设置 "prefer-stable": true 防止意外选用 beta 版。
minimum-stability 设为 beta 会怎样
设成 beta 后，Composer 默认只允许安装稳定版（stable）的包，但当你显式要求一个带 @beta 版本约束的包，或该包本身没有稳定版、只有 beta 标签时，Composer 才会拉取它。它不会自动把所有依赖都降级到 beta —— 这点很多人误以为“设了就全开闸”。
常见错误现象：composer require vendor/package 报错 Could not find package ... in a version matching...，其实是因为该包最新稳定版不存在，而你没加 @beta 后缀。
- 必须配合版本约束使用，比如
composer require monolog/monolog:@beta - 单独改
minimum-stability不足以触发 beta 包安装，还得在require字段里写明@beta或具体 beta 版本号（如^2.10@beta） - 如果项目里已有其他包锁定了
stable，它们不会被连带改成 beta；Composer 仍按最严约束合并解析
怎么在 composer.json 里正确配置 minimum-stability
直接改根 composer.json 的顶层字段即可，不需要插件或额外命令。但要注意作用域和继承规则。
示例配置：
{
"minimum-stability": "beta",
"prefer-stable": true,
"require": {
"php": "^8.1",
"laravel/framework": "^10.0@beta"
}
}
-
minimum-stability是全局策略，影响所有未显式指定稳定性后缀的依赖 - 强烈建议同时设
"prefer-stable": true，否则哪怕有 stable 版本，Composer 也可能选更“新”的 beta 版（比如2.0.0-beta.3vs1.9.5），导致意外升级 - 该字段值不区分大小写，但官方推荐小写：
dev、alpha、beta、RC、stable - 子包（比如通过
repositories引入的私有包）若未声明 stability，也受此值约束
为什么 require 里加 @beta 比改 global stability 更安全
直接在 require 字段中对单个包加 @beta，比全局设 minimum-stability 风险低得多——它只影响那个包，不影响整个依赖树的稳定性水位。
典型使用场景：你想试用某个包的 beta 版本做集成验证，但不想让 guzzlehttp/guzzle 或 symfony/http-foundation 也被拉进不稳定通道。
- 写法示例：
"monolog/monolog": "^3.0@beta"或"monolog/monolog": "3.0.0-beta1" - 这种写法优先级高于
minimum-stability，即使全局是stable，也能装指定 beta 版 - 运行
composer update monolog/monolog时，Composer 会严格按这个约束找匹配版本，不会“顺手”把其他包也升到 beta - CI 环境中尤其推荐这种方式，避免因全局 stability 变动引发不可控依赖漂移
常见坑：beta 包装不上？先检查这三处
不是配置写了就一定生效。Composer 解析稳定性时有一套隐式优先级，很多失败源于细节错位。
- 忘记运行
composer update—— 改完composer.json后，旧的composer.lock仍锁定之前解析出的版本，必须更新锁文件 - 包的真实版本标签写的是
beta1而非beta.1，但你在 require 里写了@beta，结果 Composer 找不到符合语义化版本规则的匹配项（beta1不被识别为标准 stability 标签） - 用了
repositories自定义源，但该源返回的包信息里dist.reference指向的 commit 没打任何 tag，Composer 无法推断 stability，此时即使设了minimum-stability: beta也无效
复杂点在于：stability 判断发生在版本解析阶段，不报错、不提示，只是默默跳过——你得看 composer show -a vendor/package 输出里的 versions 列表，确认目标 beta 版本是否真实存在且可访问。
