Composer如何使用prefer-stable减少问题
prefer-stable 不能阻止 dev 包安装，只能影响排序
不少开发者遇到过这样的情况：明明在配置里开启了 prefer-stable: true，结果安装完一看，vendor 目录里还是出现了 dev-main 或者 2.0.0-rc.1 这类版本。于是第一反应往往是配置没生效。其实，这里有个关键的理解偏差：prefer-stable 并非一道“防火墙”，它更像是一个“排序器”。它的作用范围，仅限于「当有多个同时满足版本约束的包可供选择」时。举个例子，如果你的约束是 "monolog/monolog": "^3.0"，而仓库里同时存在稳定的 3.1.0 和处于测试阶段的 3.2.0-beta.1，这时 prefer-stable 才会发挥作用，让 Composer 优先选择前者。
那么，哪些情况下它会“袖手旁观”呢？主要有这么几种：
- 你在
require里白纸黑字地写明了"some/pkg": "dev-main"—— 这是显式指定，Composer 自然会照单全收。 - 你的某个依赖包，它自己的
composer.json里声明了"minimum-stability": "dev"且没设prefer-stable，那么它引入的子依赖就可能带出dev版本。 - 如果
composer.lock文件已经锁定了某个dev-develop版本，而你只是运行composer install—— 这个命令会严格遵循 lock 文件，不会重新解析依赖，自然也就不会应用新的稳定性偏好。
必须配合 minimum-stability 才有意义
理解这一点至关重要：prefer-stable 表达的是一种“偏好”，而 minimum-stability 设定的才是“最低门槛”。单独设置 prefer-stable: true 却不指定 minimum-stability，在 Composer 2.2 及以后的版本中，其默认行为等同于隐式设置了 "minimum-stability": "stable"。但这种依赖默认行为的方式容易造成误判，尤其是在不同版本或环境下。
因此，更推荐的做法是显式地、完整地写明配置：
{
"minimum-stability": "stable",
"prefer-stable": true,
"require": {
"php": "^8.1",
"monolog/monolog": "^3.0"
}
}
这样一来，^3.0 这个版本约束就只会在 3.x 系列的稳定版本中进行选择，自动跳过所有的 -beta、-rc 以及 dev- 分支。
这里有个细节需要特别注意：minimum-stability 的值是一个小写字符串，可选范围包括 stable、RC、beta、alpha、dev。其中，RC 必须大写，否则配置会报错。
改完 composer.json 后必须运行 composer update
这是一个非常常见的操作误区。修改 composer.json 中的 prefer-stable 或 minimum-stability 设置，并不会自动刷新已经安装在 vendor/ 目录下的包。换句话说，如果之前已经装入了不稳定的版本，它们不会因为配置文件的改动而被自动替换掉。而且，后续执行 composer install 命令时，它只会读取现有的 composer.lock 文件，完全无视 composer.json 里这些新的稳定性配置。
要让新配置真正生效，必须执行以下命令之一：
composer update—— 这是最彻底的方式，会重新解析所有依赖关系，并更新composer.lock文件。- 或者，更安全的选择：
composer update --lock—— 它只更新composer.lock文件，而不实际改动vendor目录，非常适合在 CI/CD 环境中验证配置是否会导致依赖解析变化。 - 如果只想更新特定的几个包，避免牵一发而动全身：
composer update monolog/monolog symfony/console。
另外，也可以通过命令行参数临时启用稳定性偏好：composer update --prefer-stable。但请注意，这种方式仅对本次命令执行生效，不会写入 composer.json 配置文件。
为什么用了 prefer-stable 还会装到 beta 版？检查这三处
有时候，配置看起来一切正常，但最终还是装上了非稳定版。问题往往出在比配置本身更隐蔽的“漏点”上。以下是几个需要重点排查的环节：
require-dev里的包没清理：开发依赖常常是“重灾区”。比如phpunit/phpunit或phpstan/phpstan这类测试、静态分析工具，它们自身就可能依赖大量的dev版本。在生产环境部署前，务必使用composer install --no-dev来排除它们。- 版本约束后缀书写有误：在
require条目中，如果想指定稳定性后缀，格式必须严格。例如，"symfony/console": "^6.4 @beta"（错误，多了一个空格） → 正确的写法应该是"^6.4@beta"。一个不起眼的空格就可能导致后缀被忽略，从而引入非预期版本。 - 间接依赖的“暗度陈仓”：项目如果使用了
replace或provide字段引入了虚拟包，而实际提供这个虚拟包功能的库本身正处于dev分支，那么这种间接的依赖关系很难被顶层的prefer-stable策略直接拦住。
那么，如何最稳妥地验证当前安装的包是否符合稳定性预期呢？一个有效的方法是运行 composer show vendor/package 查看具体包的详细信息，注意输出中标记的稳定性状态。然后，再对比 composer.lock 文件中实际锁定的版本号。如果两者不一致，就说明一定有某个环节绕过了你设定的稳定性策略，需要顺藤摸瓜，仔细排查了。
