Composer Prefer-stable标志的作用：如何在开发版中优先选用稳定版？

–prefer-stable 作用是在满足依赖约束前提下优先选择 stable 版本，不禁止不稳定版本；适用于 minimum-stability 为 dev 时确保核心包稳定，且比 @stable 更灵活、比改 minimum-stability 更兼顾开发需求。

--prefer-stable 的作用很直接：在满足依赖约束的前提下，让 composer 尽量选 stable 版本，哪怕你允许安装 dev 或 beta 版本。它不禁止不稳定版本，只是“偏好稳定”——就像点外卖时勾选“优先推荐评分 4.8+ 的店”，但没评分的店只要符合地址和品类要求，依然可能被选中。

什么时候必须加 --prefer-stable？

典型场景是你的项目设置了 "minimum-stability": "dev"（比如团队用 dev 分支协同开发、或依赖某些尚未发版的功能），但你不希望核心包（如 laravel/framework、symfony/console）也跟着上 dev-main——那太容易出兼容性问题。

这时只靠 minimum-stability 不够，它只是“放行门槛”，而 --prefer-stable 才是“选版本时的排序规则”。

• 你的 composer.json 里有 "minimum-stability": "dev"，但想确保 monolog/monolog 装的是 3.5.0 而不是 4.0.x-dev
• CI 流水线里跑 composer update，怕某天某个依赖突然切到 beta 分支导致测试失败
• 你正在维护一个 SDK，对外声明“兼容 Laravel 9.x 稳定版”，但本地开发又需要临时拉 laravel/framework:dev-feature-xxx 做验证

composer require monolog/monolog --prefer-stable

--prefer-stable 和 "prefer-stable": true 有什么区别？

命令行参数 --prefer-stable 是**一次性生效**；而配置项 "prefer-stable": true 写在 composer.json 的根级，是**项目级默认行为**，后续所有 composer install / composer update 都自动带上该偏好。

两者效果一致，但落地方式不同：

• 临时加：用 composer update --prefer-stable，适合调试或 CI 单次加固
• 长期管：在 composer.json 加一行：

  "prefer-stable": true

  ，配合 "minimum-stability": "dev"，就能做到“全局宽松、关键包稳住”

• 注意：如果同时存在命令行参数和配置项，命令行会覆盖配置（Composer 行为）

为什么不用 @stable 或改 minimum-stability？

直接写 "monolog/monolog": "^3.0@stable" 看似更硬核，但它有两个硬伤：

• 它强制锁死这个包只能装 stable 版，哪怕你某天真需要 monolog/monolog:4.0.0-beta1 来测新特性，就得手动删掉 @stable，麻烦
• 它不解决其他未显式标注的包——比如你忘了给 guzzlehttp/guzzle 加 @stable，它照样可能装 dev-main

而 --prefer-stable 是“全量兜底策略”，对所有包起效，且不破坏灵活性。

至于只改 "minimum-stability": "stable"？那等于把门焊死了——所有包都只能装 stable，连 dev 分支的私有包、内部 SDK 都进不来，开发协作立刻卡住。

真正容易被忽略的一点：
--prefer-stable 不会帮你绕过版本冲突。如果某个依赖 A 要求 package/x: ^2.0，而 package/x 的最新 stable 版是 2.0.0，但另一个依赖 B 又要求 package/x: >=2.1.0，那 Composer 还是得退而求其次选 2.1.0-beta1（假设 minimum-stability 允许）。这时候，“偏好稳定”就失效了——它只在多个合法版本并存时起排序作用。