如何在使用Composer时利用prefer-stable确保生产环境的稳定性-composer-PHP中文网

必须同时配置"minimum-stability": "stable"和"prefer-stable": true，二者均须置于composer.json根级与require同级；单独设置prefer-stable仅排序不拦截，无法阻止显式声明或锁文件中的dev包。

如何在使用composer时利用prefer-stable确保生产环境的稳定性

prefer-stable 单独设 true 为什么拦不住 dev 包？

因为 prefer-stable 不是开关，它只在多个合法候选版本中做排序——先由 minimum-stability 划出“谁能进池子”，再由 prefer-stable 决定“谁先被挑中”。如果没配 minimum-stability，Composer 默认行为虽为 "stable"（2.2+），但旧项目、插件或子依赖可能绕过该默认，实际解析出 dev-main 或 2.0.0-RC1。

prefer-stable: true 单独存在时，完全不阻止 "monolog/monolog": "dev-main" 这类显式声明
若 composer.lock 里已锁着 dev 版本，composer install 会照装，完全无视 prefer-stable
某些包自身 composer.json 设了 "minimum-stability": "dev"，会局部覆盖你项目的设置

必须同时写哪两个字段？位置错就失效

minimum-stability 和 prefer-stable 必须都写在 composer.json 的根级，和 require 并列。写进 "config": { ... } 里会被完全忽略。

✅ 正确写法：

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

❌ 错误写法："config": { "prefer-stable": true } 或只写其中一个
⚠️ 注意：改完后必须运行 composer update（不是 install），否则 composer.lock 不重算，新配置形同虚设

为什么改了配置还是装了 beta 版？检查这三处

装出非稳定版，90% 是以下三个原因导致，按排查优先级排列：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

你在 require 里明写了不稳定版本，比如 "laravel/framework": "dev-main" 或 "symfony/console": "6.4.x-dev" —— Composer 把这当硬性指令，直接执行
composer.lock 里还存着旧的 dev 或 beta 记录，而你只跑了 composer install；得先删 composer.lock 和 vendor/，再 composer install 重建，或至少 composer update --lock
某个依赖包的 composer.json 自带 "minimum-stability": "dev"，它的子依赖就可能跳出你的全局控制；此时需在 require 中显式加约束，如 "vendor/pkg": "^2.5@stable"

验证 prefer-stable 是否真生效？别看 lock 文件

最直接的方式是运行 composer show monolog/monolog（把 monolog/monolog 换成你要查的包名），重点看输出里有没有 dev-、-beta、-rc 或分支名。如果有，说明没拦住——这时别急着调配置，先查 require 项是否显式写了不稳定标记，再确认 composer.lock 是不是上次用旧配置生成的。

稳定性控制从来不是单点配置问题，而是 minimum-stability + prefer-stable + require 写法 + composer.lock 状态四者联动的结果。漏掉任何一环，生产环境就可能悄悄混入 dev-main。