Composer中的prefer-stable有什么过滤作用_Composer候选版本选择逻辑【解析】

prefer-stable 仅是排序规则，非过滤器；它只在多个候选版本均满足 minimum-stability 时优先选最稳定者，必须配合 minimum-stability 使用且需运行 composer update --lock 才生效。

prefer-stable 没有过滤作用，它不拦版本、不拒安装、不删候选 —— 它只在多个满足约束的版本里，悄悄把 stable 版排到前面。

很多人第一次接触 prefer-stable 时，容易把它脑补成一个安全阀门，好像加上它，那些“不靠谱”的 dev、beta、RC 版本就自动被挡在门外了。但事实并非如此。它不会让 dev-main、2.0.0-beta.1 或 3.1.0-rc 从候选池里消失；只要这些版本满足你写的约束（比如 "monolog/monolog": "^3.0"），且没被 minimum-stability 挡住，它们就还在池子里。prefer-stable 做的唯一一件事：当池子里同时有 3.1.0（stable）和 3.2.0-beta.1（beta），它让 Composer 选前者。

常见的误解场景有不少：

• 改完 "prefer-stable": true 后跑 composer install，结果还是装了 dev-develop —— 原因很简单：composer.lock 已锁死该版本，install 根本不重新解析
• 看到 composer show -a monolog/monolog 列出一堆 dev-main (dev) 就开始紧张，以为一定会装——实际上是否被装进去，取决于你的约束是否匹配，以及 minimum-stability 是否放行
• 在 require 里写了 "some/pkg": "dev-main"，还指望 prefer-stable 能拦住——显式指定分支时，Composer 会直接跳过所有偏好逻辑

真正起效的前提：minimum-stability 必须设对

prefer-stable 单独存在时几乎无效。它的作用前提是：多个候选版本都“合法”——而谁合法，由 minimum-stability 决定。举个例子：

• "minimum-stability": "stable" → 候选池只含 stable 版，这时候 prefer-stable 毫无意义（池里只剩一个级别，没什么可选的）
• "minimum-stability": "beta" → 池子里有 stable、RC、beta，这时 prefer-stable: true 才会让 Composer 在这三者中优先 pick stable
• "minimum-stability": "dev" → 池子最宽，包含所有级别，prefer-stable 的价值最大：能确保 symfony/console 装 6.4.0 而非 7.0.x-dev，哪怕你允许了 dev

值得注意的一点是：minimum-stability 必须是小写字符串，但 RC 是唯一必须全大写的值，写成 rc 或 Rc 会直接报错 Invalid stability value "rc"。

改完配置后，不运行 update 就等于没改

composer.json 里加了 "prefer-stable": true 和 "minimum-stability": "stable"，然后只跑 composer install？ vendor/ 和 composer.lock 完全纹丝不动。

• 要让新偏好参与解析，必须运行 composer update（重解全部依赖并更新 lock）
• 想最小改动验证，用 composer update --lock：只重算版本并更新 lock 文件，不动 vendor/（适合 CI 中快速检查）
• 只想修正某几个包，避免牵连，用 composer update monolog/monolog guzzlehttp/guzzle
• 临时测试效果，命令行加 --prefer-stable：比如 composer require lara vel/framework --prefer-stable，该参数优先级高于配置项

为什么你还是看到 dev 包？三个最常忽略的漏点

即使 minimum-stability 和 prefer-stable 都配对了，dev-main 仍可能出现在 vendor/ 里。原因往往不在你自己的 composer.json：

• 某个你依赖的包（比如 acme/sdk）自己声明了 "minimum-stability": "dev"，且没设 "prefer-stable": true，它的子依赖（如 guzzlehttp/psr7）就可能被拉成 dev-master
• 你在 repositories 里加了私有 Git 仓库，并用了 "type": "vcs"，但没配 "no-api": true 或 token，导致 Composer fallback 到 Packagist 的元数据，而那里可能标记了错误的稳定性
• composer.lock 里已存着 "version": "dev-develop"，而你只在本地改了配置、没把 lock 文件推上去，CI 流水线拉的是旧 lock，自然照装旧版

生产环境上线前，建议加一行检查：grep -q '"version":"dev-' composer.lock && echo "ERROR: dev version detected" && exit 1 —— 真正管用的不是配置，是落地时的校验。