minimum-stability是单向过滤闸而非开关：设为dev仅影响未显式标注稳定性的依赖（如"^3.0"），允许dev/alpha/beta/rc/stable版本进入候选池；显式声明"dev-main"可绕过该限制；rc须全大写；必须置于composer.json根层级，配合prefer-stable:true才能在候选中优先选更稳版本。
minimum-stability 不是开关，是默认过滤闸
设成 dev 并不会“打开所有开发版”，它只影响那些没写明稳定性的依赖声明，比如 "monolog/monolog": "^3.0"。这种写法没带 @dev、@beta 后缀，Composer 才会拿 minimum-stability 去筛候选版本：设为 dev，就允许 v3.1.0-RC1、dev-main 甚至 v3.2.0-alpha2 进入比选池；设为 stable，这些全被跳过。
但只要你显式写了 "vendor/pkg": "dev-main"，哪怕 minimum-stability 是 stable，照样装——它拦不住你手写的分支名。
-
RC必须全大写，写成rc或Rc就失效，退回到默认stable - 稳定性等级严格排序：
devalpha beta RC stable，设为某一级，就只放行该级及更稳的版本 - 该字段必须放在
composer.json根层级，和require同级；塞进config或extra里完全无效
为什么 prefer-stable: true 是必配项，不是可选项
只设 "minimum-stability": "beta"，不加 "prefer-stable": true，Composer 在满足约束的多个版本中会优先选“最新”的那个，而不是“最稳”的。比如某包同时有 v2.5.0（stable）和 v2.6.0-beta2（beta），它大概率装后者——哪怕你只想用稳定功能。
"prefer-stable": true 的作用很窄：在所有满足 minimum-stability 的候选版本里，挑稳定性更高的那个。它必须和 minimum-stability 同时存在才生效，单独写没效果。
- CI 环境漏配
prefer-stable，会导致本地装v2.5.0，CI 却拉了v2.6.0-beta2，构建结果不一致 -
minimum-stability: dev+prefer-stable: true是合理组合：有 stable 就装 stable，没 stable 才 fallback 到 dev - 若
minimum-stability是stable，哪怕prefer-stable: false，也装不上dev-main——底线卡死了，偏好根本没机会触发
想装某个包的 dev 分支，别动 global minimum-stability
直接把项目 minimum-stability 改成 dev，会让所有未显式标注稳定性的依赖（包括 laravel/framework、guzzlehttp/guzzle）都倾向拉取 dev-main，极大概率导致报错或启动失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
真正安全的做法是：保持 minimum-stability 为 stable（或不写，默认就是），只对目标包单独指定版本：
- 运行
composer require vendor/package:dev-main，它会自动写入require并加@dev后缀 - 手动编辑
composer.json："vendor/package": "dev-main"或"vendor/package": "dev-main as 3.0.0"（用于版本号对齐） - 如果该包本身依赖其他不稳定子包，可能报
Your requirements could not be resolved，需顺藤摸瓜补上对应约束，比如再加一行"other-vendor/lib": "dev-develop"
改完配置后，必须跑 composer update --lock 才生效
composer.json 里改了 minimum-stability 或 prefer-stable，不运行命令，composer.lock 仍锁着旧策略下的版本，安装行为完全不变。
验证是否真生效，最简单方法是执行：
composer config minimum-stability
有输出才是写对了位置；没输出说明字段放错地方（比如塞进了 config 对象里）。
- 改完必须运行
composer update --lock，不是install，也不是update（不带--lock只更新依赖树，不重算锁策略） - 如果已误装一堆
dev版本，删composer.lock再重装比composer update --locked更彻底 - 子依赖的
minimum-stability会“传染”：你项目设stable，但依赖的 A 包自己设了dev，那 A 的子依赖 B 就可能被拉成dev-main——这时仅靠根项目的配置压不住，得看 A 包自身策略
