minimum-stability是单向过滤闸，非开关：设为stable时，未显式标注稳定性的约束（如"^3.0"）被限制只选stable及以上版本；但明写"dev-main"可绕过该限制直接安装，rc须全大写，且必须置于composer.json根层级并执行composer update --lock生效。
minimum-stability 不是“禁止 dev”，而是“默认不选低于它的版本”
它本质是一个单向过滤闸，不是开关。设成 stable，不代表你装不上 dev-main——只要你在 require 里明写 "monolog/monolog": "dev-main"，Composer 就直接跳过这个门槛，照装不误。
真正被它拦住的，是那些没显式标注稳定性的约束，比如 "monolog/monolog": "^3.0"。此时 Composer 才会按 minimum-stability 去筛候选版本：设为 beta，就只考虑 v3.0.0-beta1、v3.0.0-RC1、v3.0.0；设为 RC，beta 和 dev-main 都不会进候选池。
-
RC必须全大写，写成rc或Rc会被忽略，退回到默认stable - 稳定性等级从低到高是：
dev→alpha→beta→RC→stable - 该字段必须放在
composer.json根对象层级，和require同级；塞进config或extra里完全无效 - 改完后必须运行
composer update --lock，否则composer.lock仍锁着旧策略下的版本
prefer-stable: true 不是可选项，而是必配项
只设 minimum-stability，不加 "prefer-stable": true，等于开了门却不设优先级。比如某包同时提供 v2.5.0（stable）和 v2.6.0-beta2（beta），而你的 minimum-stability 是 beta，Composer 默认会选更新的 beta 版，而不是更稳的 stable 版。
prefer-stable: true 的作用很具体：在所有满足 minimum-stability 的候选版本中，优先挑稳定性更高的那个。它必须和 minimum-stability 同时存在才生效，单独写没效果。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- CI 环境里漏配
prefer-stable，会导致构建结果不一致——本地有，CI 没装上 stable 版 -
minimum-stability: dev+prefer-stable: true是合理组合：有 stable 就装 stable，没 stable 才 fallback 到 dev - 若
minimum-stability是stable，哪怕prefer-stable: false，也装不上dev-main——底线卡死了，偏好没机会触发
子依赖的 minimum-stability 会“传染”，但 prefer-stable 能压住
你项目设了 minimum-stability: stable，但装出来的包里还是有 dev-main？大概率是某个你依赖的包（比如 A），它自己的 composer.json 里写了 "minimum-stability": "dev"。这时 A 的子依赖 B 就可能被拉成 dev-main，哪怕你项目里什么都没写错。
这种“传染”无法靠你项目的 minimum-stability 拦住，但 prefer-stable: true 能起到压制作用：它让 Composer 在解析整个依赖树时，始终倾向更高稳定性版本，大幅降低 dev 分支意外混入的概率。
- 查问题用
composer depends <package-name></package-name>找出谁把你拉进 dev 坑 - 查包自身稳定性用
composer show -s <package-name></package-name> - 修复优先级：① 在自己
require中写死版本（如"^3.5.0"）；② 或加@stable后缀（"monolog/monolog": "^3.0@stable"）
临时装 dev 包，别动 minimum-stability，用显式约束
想试一个内部私有库的 dev-main，最安全的做法不是把全局 minimum-stability 改成 dev——那会连带拉进一堆不稳定依赖，CI 直接挂掉。
应该在 require 或 require-dev 里精准控制："myorg/internal-sdk": "dev-main as 1.0.0"，或者直接跑命令：composer require myorg/internal-sdk:dev-main。这样其他包仍走默认稳定策略，风险可控。
- 命令执行后，Composer 会自动写进
composer.json，并保持全局minimum-stability不变 - 如果
composer require vendor/pkg:dev-main不生效，先composer update --lock清掉旧锁；再检查有没有conflict规则挡住了它 - 某些私有仓库没正确配置 dist 信息，会导致 Composer 认为
dev-main不可用，输出里会出现Skipped branch
composer update --lock 这一步——改完 composer.json 不运行它，composer.lock 里还是旧规则，新配置形同虚设。
