composer默认只装stable包，需用--stability=beta、minimum-stability="beta"或版本后缀@beta显式启用beta支持，注意依赖链中各包稳定性须匹配且优先级为命令参数＞@后缀＞全局配置。
直接安装 beta 版本包时 Composer 报错“Could not find package”
默认情况下，Composer 只允许安装 stable（稳定）版本，哪怕你写了 "dev-master" 或 "1.0.0-beta.2"，它也可能跳过或报找不到。这不是包不存在，而是稳定性约束在拦截。
解决方法是显式告诉 Composer：允许接受更低的稳定性级别。最常用的是在 require 命令中加 --stability=beta 或缩写 -s beta：
composer require vendor/package:1.0.0-beta.2 --stability=beta
注意：--stability 只影响本次命令，不改变项目全局配置。
- 可选值包括：
stable、RC、beta、alpha、dev - 值越靠后，允许的版本越不稳定；
dev允许dev-master和分支别名 - 如果包的
version字段在composer.json里没显式声明为1.0.0-beta.2，Composer 可能无法识别其稳定性，此时需配合--prefer-source或检查包仓库的dist/source发布方式
修改 composer.json 的 minimum-stability 和 prefer-stable
想让整个项目默认接受 beta 包，而不是每次加参数，就得改根目录下的 composer.json。关键字段是 minimum-stability 和 prefer-stable：
{
"minimum-stability": "beta",
"prefer-stable": true
}
minimum-stability 设定项目允许的最低稳定性（全局开关），prefer-stable 表示：当有 stable 版本可用时，优先装 stable 而不是按最低稳定性硬选 beta —— 这能避免意外升到不稳定的版本。
- 设成
"beta"后，composer require vendor/package（不带版本）可能装上1.0.0-beta.2，但若有1.0.0就仍会选 stable - 如果删掉
prefer-stable或设为false，只要满足minimum-stability，就会选最新匹配版本（比如dev-main），风险明显上升 - 该设置对已 lock 的包无效；运行
composer update才会重新评估稳定性
require 中用 @beta 后缀强制指定稳定性
比改全局配置更轻量的做法，是在 require 里直接给版本加稳定性后缀，例如：
"vendor/package": "1.0.0@beta"
这种写法等价于 --stability=beta，但写死在 JSON 里，适合长期依赖某个 beta 版本的场景。
- @ 后缀支持：
@stable、@RC、@beta、@alpha、@dev - 它比
minimum-stability优先级更高：即使全局设了stable，加了@beta仍能装 - 注意不要和分支别名混用，比如
"dev-main@beta"是非法的；分支本身属于dev类型，不能叠加@beta
常见陷阱：beta 包装不上，却提示 “Your requirements could not be resolved”
这往往不是稳定性问题，而是依赖冲突。Composer 在解析 beta 版本时，会严格校验其 require 字段里所有依赖是否也满足当前项目的稳定性策略。
比如你要装的 beta 包依赖 "monolog/monolog": "^3.0@alpha"，但你的项目 minimum-stability 是 beta，那 alpha 就被拒了——错误信息不会直接说“因为 monolog 是 alpha”，只会泛泛报依赖无法满足。
- 用
composer why-not vendor/package:1.0.0-beta.2查谁在阻止安装 - 临时把
minimum-stability改成alpha测试是否真由子依赖引发 - 某些包的 beta 版本未正确声明
type或version，导致 Composer 无法识别其稳定性等级，此时需看该包的composer.json源码
稳定性设置看着简单，实际生效链条很长：从命令参数 → composer.json 全局配置 → 单包 @ 后缀 → 依赖包自身的稳定性声明 → Packagist 元数据缓存。调不通时，一层层往上游查才不容易卡住。
