Composer怎么设prefer-stable_Composer稳定版优先配置方式【实用】

prefer-stable 单独设为 true 没效果，必须和 minimum-stability 配合使用，且改完后不运行 composer update –lock 就等于没改。

prefer-stable 不是开关，只影响版本排序

它只在多个满足 require 约束、又都符合 minimum-stability 门槛的版本中起作用。比如你写 "monolog/monolog": "^3.0"，同时有 3.5.0（stable）和 3.6.0-beta1（beta），且 minimum-stability 是 beta，这时 prefer-stable: true 才会让 Composer 选 3.5.0。

以下情况它完全不干预：

你在 require 里明写 "some/pkg": "dev-main" 或 "some/pkg": "@dev"composer.lock 已锁死一个 dev 版本，你只跑 composer install某个依赖包自己的 composer.json 设了 "minimum-stability": "dev"，它的子依赖可能绕过你的偏好

正确配置位置和结构

prefer-stable 必须放在 composer.json 的根对象层级，和 require、minimum-stability 并列——塞进 "config" 里就彻底失效。

推荐的最小安全组合是：

{ "minimum-stability": "stable", "prefer-stable": true, "require": { "php": "^8.1", "monolog/monolog": "^3.0" }}

注意："minimum-stability": "stable" 是底线，"prefer-stable": true 是优化策略；漏掉前者，后者基本没意义。

生效必须靠 composer update –lock

改完 composer.json 后，仅 composer install 不会重算依赖，composer update 也不够保险——必须加 –lock 参数，强制更新 composer.lock 文件。

常见误操作：

只改 JSON 就以为完事了运行 composer update monolog/monolog 却漏掉其他包，导致部分依赖仍按旧规则解析CI 环境没同步这个命令，本地装的是 stable，CI 装的是 dev

验证是否真生效

最可靠方式：删掉 vendor 和 composer.lock，再执行 composer install。看装出来的包有没有 dev-、-beta、-rc 这类后缀。

快速检查已安装包来源：

composer show monolog/monolog

输出里如果带 source 字段且 URL 含 dev- 或分支名，说明 prefer-stable 没拦住——优先查 require 项是否显式写了不稳定标记，再确认 composer.lock 是不是上次用旧配置生成的。

真正容易被忽略的点是：稳定性控制不是单点配置问题，而是 minimum-stability + prefer-stable + require 写法 + composer.lock 状态 四者联动的结果。少一个环节，行为就不可控。