Composer如何理解稳定性标记_Composer稳定性标记详解

Composer 稳定性标记：门槛与偏好，一字之差天壤之别

先明确一个核心原则：Composer 的 minimum-stability 是硬性过滤门槛，它决定了哪些版本有资格进入候选池；而 prefer-stable 仅仅是在池子内部优先选择稳定版，它绝不改变过滤规则本身。这个区别，是理解后续所有问题的关键。

默认情况下，Composer 只安装 @stable 版本。至于 @dev、@beta、@RC 这些标记，都属于需要你显式“开闸放水”的行为——如果没加配置或者格式写错，Composer 就会直接无视它们。

为什么 composer require vendor/pkg:@beta 还会报 “could not find package”？

问题往往不出在命令本身，而在于项目根本没给 beta 版本打开准入权限。Composer 的工作流程是分两步的：先根据 minimum-stability 过滤出一个候选版本池，然后才在这个池子里匹配你写的版本约束。所以，如果你的 composer.json 里没有设置 "minimum-stability": "beta"，那么就算你明确写了 @beta，Composer 也根本不会把类似 v2.0.0-beta1 这样的版本放进可选列表，自然就找不到了。

这里有几个高频踩坑点，值得逐一核对：

• @rc（全小写）会被 Composer 完全忽略，行为会退回到默认的 @stable；必须写成全大写的 @RC 才行。
• ^2.0@beta 这种写法，只匹配带 -beta 后缀的标签，它不会匹配 dev-main 分支，也不会匹配 2.0.0-RC1。
• 子依赖包如果自己声明了 "minimum-stability": "dev"，会覆盖你项目的全局设置。结果就是你明明设了 stable，最终却拉下来一个 dev 版本。
• 最后，别忘了用 composer show vendor/pkg --allbeta 标签，而不是只有 RC 或者 dev-main。

minimum-stability 和 prefer-stable，到底谁说了算？

这就回到了开篇的核心区别。你可以把 minimum-stability 想象成招聘的“学历门槛”，它决定哪些简历能进HR的文件夹；而 prefer-stable 则是HR在筛选合格简历时，“偏好有更多经验的那位”。后者只负责在入围者里挑，绝不负责改变入围标准。

• 场景一：设置 "minimum-stability": "beta" 且 "prefer-stable": true。当候选池里同时有 2.0.0（稳定版）和 2.0.0-beta1 时，Composer 会优先选择前者。但如果池子里只有 2.0.0-RC1，它也会照装不误，因为 RC 的稳定性等级高于等于 beta，符合门槛要求。
• 场景二：只设 "prefer-stable": true 但不设 minimum-stability。这基本是无效操作，因为默认的 minimum-stability 就是 stable，候选池里本来就没有非稳定版本，自然无“偏好”可言。
• 那么，想彻底锁死只安装稳定版怎么办？必须同时满足两个条件："minimum-stability": "stable" 加上 "prefer-stable": true。前者把非稳定版挡在门外，后者在多个稳定版中帮你选最合适的。

什么时候该用 @dev，什么时候该用 --stability=dev？

这关乎作用范围。@dev 是“精准授权”，只对指定的那个包生效，并且明确指向某个分支或开发快照。--stability=dev 则是“临时放宽全局门槛”，它会影响本次命令中所有没有显式指定稳定性的依赖。

• 直接运行 composer require vendor/pkg:dev-main 很可能会失败，除非你同时加上 --stability=dev 参数，或者已经在项目中设置了 minimum-stability: dev。
• 记住，dev-main 不是语义化版本号，它是一个分支别名。它不遵循版本迭代逻辑，每次 composer update 都可能拉取新的提交，因此绝对不适合生产环境。
• 对于私有包或内部调试，使用 @dev 更安全，因为它只影响特定包。而在 CI/CD 流水线中临时安装一个 beta 包进行测试，使用 composer update vendor/pkg --stability=beta 这样的命令则更为可控。
• @dev 允许的范围其实很宽：它不仅包括 dev-main、dev-develop 这类分支，也包括 3.1.0-dev 甚至 3.1.0-alpha1（只要包作者打了这个标签）。

话说回来，真正容易被忽略的，是稳定性等级的单向过滤性。设置 minimum-stability: "beta"，就意味着你永远看不到 dev 级别的版本；设置 "RC"，就永远看不到 beta 以下的版本——这不是“推荐”，而是“禁止”。至于 @RC 必须全大写这类细节，在 CI 日志报错时，往往让人翻遍配置文档才恍然大悟，原来问题出在大小写上。