prefer-stable 是 Composer 的版本偏好配置，启用后在满足 minimum-stability 前提下优先选择更稳定的版本；需配合 minimum-stability 使用，单独设置不阻止显式声明的 dev 版本。
prefer-stable 是 Composer 用来控制包版本选择倾向的关键配置项——它不会强制安装稳定版，但会让 Composer 在满足依赖约束的前提下，优先选择 stable（即 stable、RC、beta 等标记为稳定级别的版本），而不是默认可能拉取 dev-master 或带 -dev 后缀的开发快照。
如何全局或项目级启用 prefer-stable
该配置支持两种设置方式，行为略有差异：
- 项目级：写入当前项目的
composer.json的config段，仅影响本项目 - 全局级：执行
composer config -g prefer-stable true，影响所有后续项目（除非被项目级覆盖）
推荐优先用项目级配置，避免意外污染其他项目。示例写法：
{
"config": {
"prefer-stable": true
}
}
注意："prefer-stable": true 必须配合 "minimum-stability": "stable" 才能真正限制只装稳定版；单独设 prefer-stable 时，若依赖明确要求 "dev-main" 或 "@dev"，Composer 仍会照装。
minimum-stability 和 prefer-stable 的关系
这两个配置常被混淆，但作用完全不同：
-
minimum-stability是“准入门槛”：定义允许安装的最低稳定性级别（如设为stable，则beta及以下默认不被接受） -
prefer-stable是“选版本时的偏好”：在多个满足minimum-stability的候选版本中，优先挑更稳定的那个
典型组合是：
"minimum-stability": "stable", "prefer-stable": true
此时 Composer 不会装任何 beta、RC 或 dev 包；若必须临时引入一个 RC 版本的包，得在 require 中显式写成 "vendor/pkg": "2.0.0-RC1"，否则会被拒绝。
为什么有时 prefer-stable 像没起作用？
常见误解是开了 prefer-stable 就一定不装 dev 包——实际是否生效，取决于依赖声明本身：
- 如果某个包在
require中写的是"monolog/monolog": "^3.0"，且3.0.0已发布为 stable，则prefer-stable会生效，装3.0.0 - 但如果该包尚未发 stable 版，最新只有
3.0.0-RC2，而你又没设minimum-stability，Composer 默认按stable解析，反而可能跳过 RC 直接报错；此时需显式降级minimum-stability到RC，再靠prefer-stable保证不退到dev - 某些包的
composer.json自身声明了"minimum-stability": "dev"，会覆盖你项目的设置，导致子依赖仍拉 dev 版
查证实际安装了什么版本，最直接的方式是运行 composer show monolog/monolog，看输出里的 versions 行是否含 -dev 后缀。
CI/CD 中建议显式锁定 stability 行为
在自动化流程里，不能依赖开发者本地的全局配置。务必在项目 composer.json 中同时声明：
{
"minimum-stability": "stable",
"prefer-stable": true,
"config": {
"sort-packages": true
}
}
这样能确保不同环境行为一致。另外，上线前建议跑一次 composer update --dry-run，观察是否意外引入了 -dev 版本——这类变动往往藏在间接依赖里，容易被忽略。
