Composer默认拒绝安装beta、rc等非稳定版，需用--stability=beta/rc或@beta/@rc显式指定；版本号必须与包内composer.json的version字段或Git tag严格匹配，否则静默回退到stable。
直接用 composer require 加版本号和稳定性标记
Composer 默认拒绝安装 beta、rc 这类非稳定版，不是网络问题，是策略拦截。最稳妥的做法是不改全局配置，只对目标包临时放宽限制。
- 装指定
beta版本：运行composer require vendor/package:2.5.0-beta1 --stability=beta - 装最新
beta（比如2.5.0-beta2）：用composer require vendor/package:^2.5@beta - 装
rc版本：同理，composer require vendor/package:3.0.0-rc1 --stability=rc
注意：--stability=beta 只影响当前命令，不会污染项目其他依赖；而写成 vendor/package:2.5.0-beta1@dev 是错的——@dev 和 @beta 冲突，Composer 会报错解析失败。
为什么 composer require vendor/package:2.5.0-beta1 常常失败？
表面看命令没错，但实际失败原因很具体：Composer 会严格比对包内 composer.json 的 version 字段或 Git tag 名称。哪怕远程仓库打了 v2.5.0-beta1 标签，但包自己声明的是 "version": "dev-main"，那 2.5.0-beta1 就无法匹配。
- 先确认真实可用版本：
composer show -a vendor/package，看输出里有没有你想要的 tag - 常见合法写法只有这些：
2.5.0-beta1、^2.5@beta、dev-main#abc123（某次提交） - 错误写法示例：
2.5.0-beta（缺数字）、2.5.0.BETA1（大小写/分隔符错）、2.5.0-beta1@dev（双重稳定性标记）
改 minimum-stability 风险有多大？
在 composer.json 里加 "minimum-stability": "beta" 看似一劳永逸，但它会让所有后续 require 或 update 都可能拉到 beta 版，哪怕你没意识到——比如某个间接依赖突然出了个 beta 版，就被自动带进来了。
- 更安全的组合是：
"minimum-stability": "stable"+"prefer-stable": true+ 单独对目标包用@beta约束 - 如果真要设全局
beta，务必同步加"prefer-stable": true，否则连^3.0这种约束都可能命中dev-main - 改完
composer.json后，记得删掉composer.lock里对应包的条目，再跑composer update vendor/package --with-all-dependencies，否则 lock 文件会缓存旧策略
装完发现还是 stable 版？检查这三处
命令返回 success，但 composer show vendor/package 显示的仍是 2.4.0，说明 Composer 没有真正降级——它优先满足已有依赖图，而不是你的新指令。
- 检查是否已有其他包依赖了更高版本（如
another/pkg要求^2.5），导致 Composer 拒绝降级到2.5.0-beta1 - 检查
composer.json中是否已存在同名包但约束更宽（如"vendor/package": "^2.4"），新require命令没覆盖它 - 运行
composer update vendor/package --with-all-dependencies强制重算，观察日志里是否有Downgrading字样，没有就说明被锁住了
预发布版本不是“能装就行”，关键在版本号是否被源端正确定义、本地约束是否精准匹配、以及整个依赖图是否允许它落地——漏掉任一环，都会静默回退到 stable。
