最安全的方式是使用 --stability=beta 参数临时放宽稳定性限制，而非修改 minimum-stability；后者会全局降低稳定性门槛，导致间接依赖也被升级到 beta 版，引发不可控风险。
直接装 beta 版本，别改 minimum-stability
想装 vendor/package:2.5.0-beta1 却失败？不是包不存在，也不是网络问题，而是 Composer 默认只接受 stable 版本。它看到 -beta1 标签就直接过滤掉，根本不会去解析。
最安全的做法是加 --stability=beta 参数，只影响当前命令：
composer require vendor/package:2.5.0-beta1 --stability=beta- 或者装该系列最新 beta：
composer require vendor/package:^2.5@beta - 不用动
composer.json，也不用删composer.lock，命令执行后它会自动记录精确版本和稳定性标签
改 minimum-stability 是高风险操作：一旦设成 "beta"，所有没显式锁定版本的依赖（包括间接依赖）都可能被拉进 beta 状态，比如 monolog/monolog 的 ^3.0 可能装到 3.0.0-beta2 而不是 3.0.1。
composer show -a 确认 beta 版真实存在
运行 composer show -a vendor/package，看输出里有没有带 (beta) 标注的 2.5.0-beta1。如果没有，说明这个版本压根没被 Packagist 收录，或者 tag 名不匹配。
常见陷阱：
- 版本字符串必须严格一致：
2.5.0-beta1≠2.5.0.BETA1、2.5.0-beta（缺数字）、2.5.0-beta1@dev（冲突标记） - 如果包的
composer.json里写的是"version": "dev-main"，哪怕 Git 有v2.5.0-beta1tag，Composer 也识别不了 - 某些包把 beta 版发布在
dist模式下但没打正式 tag，show -a就看不到
装完还是 stable？检查三点
命令返回 success，但 composer show vendor/package 显示的仍是旧版，说明根本没生效。
立刻检查：
-
composer.lock里该包的条目是否已更新——没变就说明依赖解析绕过了你的请求 - 有没有其他已安装包强制要求更高 stable 版，比如
another/pkg要求^2.6，导致 Composer 拒绝降级到2.5.0-beta1 - CI 或部署环境是否用了
--no-interaction并缓存了旧的composer.lock，实际没走你刚写的命令
本地调试开发版：用 path 类型仓库覆盖 Packagist
如果你不只是想装个 beta，而是要边改边测——比如正在给某个包提 PR，需要在主项目里实时验证修改效果——repositories + path 是唯一靠谱方案。
在项目 composer.json 里加：
{
"repositories": [
{
"type": "path",
"url": "../my-package-fix"
}
],
"require": {
"vendor/package": "@dev"
}
}
关键点：
-
url必须是相对路径，指向你本地克隆的包目录 -
require里写@dev，否则 Composer 还是优先走 Packagist - 改完子包代码，主项目里
composer dump-autoload就能立刻生效，不用反复require或update - 这个配置只对当前项目生效，不影响全局或其他项目
真正麻烦的从来不是怎么装 beta，而是怎么确认它真被用了、没被其他约束顶掉、也没在 CI 里被缓存掩盖——这些地方一漏，测试就白做了。
