prefer-stable是排序偏好而非开关，仅在minimum-stability划定的候选池内优先选择更稳定版本；minimum-stability才是硬性过滤门槛，决定哪些版本有资格进入候选池。
prefer-stable 是什么，它和 minimum-stability 有什么区别
prefer-stable 是一个布尔开关，控制 Composer 在满足 minimum-stability 前提下“是否优先选更稳定的版本”。它不放宽安装门槛，只影响同级版本里的选择倾向。
比如你设了 "minimum-stability": "beta"，那 stable、RC、beta 都合法；但如果有 v2.0.0（stable）和 v2.1.0-beta1（beta）都符合版本约束，prefer-stable: true 就会让 Composer 选 v2.0.0，而不是更新但更不稳的 beta。
而 minimum-stability 是闸门——设成 beta，alpha 和 dev 版本根本不会进候选池，prefer-stable 对它们完全没作用。
如何正确启用 prefer-stable 并避免误判
它必须显式写在 composer.json 的根级，不能放在 require 或其他嵌套字段里：
{
"minimum-stability": "beta",
"prefer-stable": true,
"require": {
"monolog/monolog": "^3.0"
}
}
常见误操作：
- 只改
minimum-stability却漏掉prefer-stable，结果装到dev-main而不是已发布的beta版 - 设了
"prefer-stable": false（等价于不写），但以为能强制选 dev —— 实际上它只影响“同稳定性级别内的排序”，不改变最低准入线 - 在 CI 环境中用
--no-interaction运行时，没确认composer.lock是否已包含prefer-stable生效后的解析结果，导致本地和构建环境行为不一致
加了 @dev 后 prefer-stable 还起作用吗
不起作用。显式指定稳定性后缀会覆盖 prefer-stable 的排序逻辑。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
例如：
-
composer require monolog/monolog:@dev：不管prefer-stable是 true 还是 false，都会装dev-main（或最新 dev 分支） -
composer require monolog/monolog:@beta：只会找带-beta后缀的版本，哪怕有stable版也忽略 -
composer require monolog/monolog:^3.0+"prefer-stable": true：会在所有满足^3.0且 ≥minimum-stability的版本中，挑最稳定的那个（可能是3.0.0，而不是3.1.0-beta2）
注意：@dev 不等于 dev-main —— 如果包只有 dev-feature/x 分支而没有 dev-main，@dev 会失败，必须写全分支名：dev-feature/x。
为什么 prefer-stable 开启后有时还是装到了 dev 分支
因为项目里可能根本就没有满足版本约束的 stable、RC 或 beta 版本。
典型场景：
- 你 require
"some/package": "^2.0"，但该包最新 tag 是v2.0.0-alpha1，且minimum-stability是alpha - 此时
prefer-stable: true没意义——alpha就是当前可选范围里“最稳定”的级别，Composer 只能装它 - 想避开 alpha，就得把
minimum-stability提到beta或更高，或者直接锁死一个已存在的 stable 版本："some/package": "1.5.0"
真正容易被忽略的是：这个行为不报错，也不警告，它就静默地装了你没意识到其实并不够稳的版本。
