prefer-stable 是候选池内的排序偏好而非开关，仅当 multiple versions satisfy constraints and minimum-stability allows them does it prioritize stable ones; it requires minimum-stability setting and composer update to take effect.
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 就永远不碰偏好逻辑。别指望它自动修正历史遗留的不稳定依赖。
