minimum-stability是composer.json顶层字段，仅约束未显式标注稳定性的依赖（如"^3.0"），对"@beta"或"dev-main"等显式声明的包无效；合法值为dev/alpha/beta/rc/stable（rc须全大写），需配合prefer-stable:true生效。
minimum-stability 是什么，它到底管谁？
minimum-stability 是 composer.json 顶层字段，不是命令行参数，也不是插件配置。它只对「没显式声明稳定性」的依赖起作用——比如你写 "monolog/monolog": "^3.0"，Composer 才会按这个值去筛版本；但如果你写 "monolog/monolog": "^3.0@beta" 或 "monolog/monolog": "dev-main"，它就完全绕过该设置。
它的本质是过滤器，不是质量担保：设成 "stable" 不代表装出来的包一定没 bug，只是说它得是形如 3.5.0 这样的无后缀标签；设成 "beta" 就允许 3.5.0-beta1 和 3.5.0-rc2，但不会拉 3.5.0-alpha3。
合法值只有五个，RC 必须全大写
合法值严格限定为：dev、alpha、beta、RC、stable（大小写不敏感，但推荐小写，唯独 RC 必须全大写——写成 rc 或 Rc 会被忽略，Composer 退回到默认 stable）。
常见错误现象：
- 改完
composer.json却没生效 → 忘了运行composer update --lock，composer.lock没刷新，旧约束还在起作用 - 写了
"minimum-stability": "beta"，却装不上某个包 → 用composer show -a vendor/package查真实发布记录，很可能那个包压根没发过 beta 版本，只有v2.0.0（stable）和dev-main（dev） - 私有仓库或 GitHub 上刚推的分支未同步到 Packagist →
composer show -a查不到，得手动在repositories里加源
为什么光设 minimum-stability 不够？prefer-stable 是必须搭档
只设 "minimum-stability": "beta"，而 "prefer-stable": false（默认），Composer 可能选 3.0.0-beta.4 而不是已存在的 2.9.5（stable），哪怕后者完全满足 ^2.0 约束——因为语义化版本排序优先“新”，不是“稳”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
"prefer-stable": true 的作用很实在：在所有满足 minimum-stability 的候选版本里，挑最稳定的那个。它必须和 minimum-stability 同时存在才生效，单独写没意义。
生产环境推荐组合：
{
"minimum-stability": "stable",
"prefer-stable": true
}
想临时试一个 beta 包？别动全局配置
全局调低 minimum-stability 会影响整个依赖树，风险高。更安全的做法是在 require 里单点指定：
-
"vendor/package": "^2.5@beta"→ 允许2.5.x-beta及以上 beta 版，不影响其他包 -
"vendor/package": "dev-feature-branch as 2.5.0"→ 强制装某分支，同时 alias 成稳定版号，避免 autoload 或类型提示报错
这种写法优先级高于 minimum-stability，且改完后仍需 composer update vendor/package --with-all-dependencies，不能只靠 install —— lock 文件锁的是旧版本，不触发解析就不会更新。
真正容易被忽略的是：稳定性标记只是发布流程的快照，不是兼容性承诺。哪怕 minimum-stability 设成 stable，也不能防止下游包在 patch 版本里偷偷改 break change——它只拦得住明显带后缀的版本，拦不住语义化版本规则本身失效的地方。
