minimum-stability是全局硬性过滤闸而非建议开关：设为dev仅允许未显式标注稳定性的依赖（如"^3.0"）纳入dev/alpha/beta/RC/stable候选池；显式声明"dev-main"可绕过限制；RC须全大写；必须置于composer.json根层级，配合prefer-stable:true才能在候选中优先选更稳版本。
稳定性标识（如 @stable、@dev、@RC）不是可选修饰，而是 Composer 解析版本时的硬性过滤开关——它直接决定某个包版本是否被纳入候选集，哪怕该版本号完全满足语义化约束。
为什么 composer require foo/bar:^2.0 有时装不到 2.0.0？
因为 2.0.0 可能带 @dev 标签（比如是 Git tag + dev-master 分支推上去的），而 Composer 默认只接受 @stable 版本。即使你写了 ^2.0，只要该版本未被 Packagist 标记为稳定，它就不会进入依赖解析流程。
- 默认行为：Composer 隐式添加
@stable后缀，等价于foo/bar:^2.0@stable - 显式写
@dev会绕过稳定性检查，但可能拉下未测试的快照版（如dev-main或2.0.x-dev） -
@RC、@beta、@alpha属于“预发布稳定性等级”，需显式声明才启用 - 运行
composer show foo/bar可看到每个版本末尾标注的稳定性标签（如2.0.0 Stable或2.1.0-RC1 RC）
minimum-stability 是全局稳定性阈值，不是建议值
它在 composer.json 的根级配置，定义整个项目允许接纳的最低稳定性等级。一旦设为 "minimum-stability": "beta"，所有包（包括间接依赖）都不得使用 @alpha 或 @dev 版本，否则解析失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 合法值按严格度升序：
stable<RC<beta<alpha<dev - 设为
dev不代表“放开一切”，只是允许dev-前缀或无标签的开发版；仍受版本约束（如^2.0）限制 - 单个包可覆盖全局设置：
"foo/bar": "^2.0@dev"在minimum-stability: stable下依然生效 - 修改
minimum-stability后必须运行composer update，否则composer.lock中旧的稳定版不会自动降级
预发布版本（-alpha、-beta）如何参与 ^ 和 ~ 计算？
它们不改变语义化版本主干比较逻辑，但会触发额外的稳定性筛选。例如 ^1.2.0-beta.1 表示 “>=1.2.0-beta.1 且 minimum-stability 是否允许 beta 级别。
-
1.2.3-beta.1和1.2.3被视为不同版本，后者稳定性更高，优先被选中 -
~1.2.0-beta.1不会匹配1.2.3（因~要求补丁号不能跨.x边界，而beta.1 → 3视为 patch 升级，但稳定性跃迁不被~隐含支持） - 用
composer prohibits foo/bar查看哪个依赖强制锁定了低稳定性版本，比猜更可靠
真正容易被忽略的是：稳定性标识在 lock 文件里固化后，composer install 就不再校验 Packagist 上的当前标签状态——哪怕那个 dev-main 已被删掉，只要 lock 里还存着它的 commit hash，它就照装不误。
