如何通过Composer的prefer-stable配置来指定包的最小稳定版本？

本文共计814个文字，预计阅读时间需要4分钟。

prefer-stable 不是开启，minimum-stability 才是门槛；仅配置 prefer-stable，而不设 minimum-stability，在 Composer 2.2+ 中等效于 minimum-stability: stable。

minimum-stability 决定哪些版本有“入场资格”

它是一个过滤器，不是排序器。Composer 按 stable > RC > beta > alpha > dev 的优先级对所有可用版本打分，然后只保留 ≥ 该值的版本进入候选池。

• "minimum-stability": "stable" → 只考虑带正式版本号（如 3.5.0）或 @stable 标记的包；dev-main、2.0.0-beta1 直接被筛掉
• "minimum-stability": "beta" → 3.0.0-RC2 和 2.9.0 都能进池子，但 dev-main 仍被拒
• 它默认作用于所有未显式标注稳定性的依赖；一旦你在 require 里写了 "monolog/monolog": "dev-main"，这条规则就被绕过

prefer-stable 只在候选池里“挑更稳的那个”

它不扩大或缩小候选池，只影响池内多个满足约束的版本之间的排序。比如 "monolog/monolog": "^3.0" 同时匹配 3.4.0（stable）和 3.5.0-RC1（RC），且 minimum-stability 允许 RC，则 prefer-stable: true 会让 Composer 选 3.4.0。

• 必须写在 composer.json 顶层，和 require、minimum-stability 并列，不是放在 config 里——"config": { "prefer-stable": true } 完全无效
• 改完后必须运行 composer update（不是 install），否则 composer.lock 不重算，偏好不生效
• 已锁在 composer.lock 里的 dev-main 不会自动被替换；得靠 composer update monolog/monolog 或全量更新触发重解

为什么加了 prefer-stable 还装了 dev 包？

三个最常见原因：

• 你在 require 里明写了分支，比如 "laravel/framework": "dev-main" —— Composer 照单全收，无视所有偏好
• 某个你依赖的包（如 vendor/a）自己设了 "minimum-stability": "dev"，又没配 prefer-stable，它的子依赖（如 monolog/monolog）就可能把 dev-main 带进来
• composer.lock 已锁定一个 dev 版本，而你只运行了 composer install —— 它只还原，不决策

验证当前装的是不是稳定版

运行 composer show vendor/package，看输出里有没有 dev-、-alpha、-beta、-RC 这类后缀。如果有，说明要么约束太松，要么某处显式指定了开发版。

真正容易被忽略的点是：稳定性策略只在「版本解析阶段」起作用，而解析结果完全固化在 composer.lock 里；只要 lock 文件没变，install 就永远不碰偏好逻辑。别指望它自动修正历史遗留的不稳定依赖。