直接装 beta 版本最安全的方式是使用 --stability=beta 参数，而非修改 minimum-stability；后者会全局降低稳定性门槛，导致间接依赖也被升级到 beta 版，引发不可控风险。

直接装 beta 版本，不改全局配置最安全；改 minimum-stability 是高风险操作，容易连带升级其他依赖到不稳定状态。

为什么 composer require vendor/package:2.5.0-beta1 会失败

不是网络问题，也不是包不存在，而是 Composer 在解析时发现：当前 minimum-stability 是 stable（默认），而 2.5.0-beta1 的稳定性标签是 beta，低于门槛，直接过滤掉。

• 运行 composer show -a vendor/package 确认该版本真实存在，且括号里标的是 (beta)
• 检查版本字符串是否严格匹配——2.5.0-beta1 不能写成 2.5.0.BETA1、2.5.0-beta（缺数字）或 2.5.0-beta1@dev（冲突标记）
• 如果包的 composer.json 里 "version" 字段写的是 "dev-main"，那 2.5.0-beta1 就无法被识别，哪怕 Git tag 存在

临时安装 beta 版的正确命令

用 --stability=beta 参数，只影响当前命令，不污染项目策略：

composer require vendor/package:2.5.0-beta1 --stability=beta

或者装该系列最新 beta：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

composer require vendor/package:^2.5@beta

• 不需要提前改 composer.json，也不需要删 composer.lock
• 命令执行后，composer.lock 会自动记录该包的精确 beta 版本和稳定性标签
• 后续 composer update 不会自动升到下一个 beta，除非你再次显式指定

改 minimum-stability 的实际影响

在 composer.json 根对象加 "minimum-stability": "beta" 后，所有未显式锁定稳定版本的约束都会“松动”：

• "monolog/monolog": "^3.0" 可能装 3.0.0-beta2 而不是 3.0.1
• 间接依赖（如 A → B → C）也可能被带进 beta 版，即使你没主动 require C
• 必须同步加 "prefer-stable": true，否则 ^3.0 这种写法可能命中 dev-main
• 改完要运行 composer update vendor/package --with-all-dependencies，仅 install 不会重算依赖图

装完还是 stable？检查这三点

命令返回 success，但 composer show vendor/package 显示的仍是旧 stable 版，说明根本没生效：

• 确认 composer.lock 中该包条目是否已被更新——没更新就说明依赖解析绕过了你的新要求
• 检查是否有其他已安装包依赖更高 stable 版（如 another/pkg 要求 ^2.6），导致 Composer 拒绝降级到 2.5.0-beta1
• CI 或部署环境是否用了 --no-interaction + 缓存的 composer.lock，跳过了重新解析步骤

真正难处理的从来不是怎么写命令，而是当多个包对同一依赖提出不同稳定性要求时，Composer 的 SAT 解析器如何取舍——这时候得靠 composer why-not vendor/package:2.5.0-beta1 看具体卡在哪一层约束上。