--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 允许）。这时候，“偏好稳定”就失效了——它只在多个合法版本并存时起排序作用。
