Composer 的 @dev、@alpha、@beta 是稳定性标记，用于指定依赖允许安装的版本稳定程度：@dev 最宽松，支持开发分支；@alpha/@beta 向下兼容（如 @beta 可装 alpha 和 beta）；@RC 必须大写；@stable 等价于无标记，仅匹配正式版。
Composer 的 @dev、@alpha、@beta 是什么
它们不是版本号的一部分，而是附加在包名或版本约束后的“稳定性标记”，告诉 Composer：这个依赖允许安装到哪个稳定程度的版本。
比如 composer require monolog/monolog:^3.0@beta，意思是“装 3.x 系列里最新的 beta 版”，哪怕它实际是 3.0.0-beta2；而 monolog/monolog:dev-main 就是直接拉 main 分支的最新快照，不走任何标签逻辑。
- @dev 允许 dev-* 分支、
dev-main、dev-develop—— 最宽松，适合本地调试或内部私有包 - @alpha / @beta / @RC（注意必须大写）会自动向下兼容：设 @beta 就能装 alpha 和 beta，但不会装 dev
- @stable（等价于不写标记）只认无后缀的正式版，如
2.10.0或2.10.0-stable - RC 必须全大写：
@RC有效，@rc或@Rc会被忽略，退回到默认stable行为
minimum-stability 和 prefer-stable 到底怎么配
minimum-stability 是“准入门槛”，prefer-stable 是“选版本时的偏好”——这两个配置必须一起看，单独设任何一个都容易出偏差。
比如你项目 composer.json 里写了：
"minimum-stability": "beta",<br>"prefer-stable": true那 Composer 会在所有满足 beta 及以上（即 beta / RC / stable）的候选版本中，优先挑 stable 的；但如果某包只有
2.0.0-RC1 没发 stable 版，它还是会装 RC 版，不会报错跳过。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 想彻底锁死只装 stable？必须同时设
"minimum-stability": "stable"+"prefer-stable": true - 只想临时给某个包用 dev 版，别动全局配置：直接在
require里写"vendor/pkg": "dev-main"，它会覆盖minimum-stability - 子依赖包自己声明了
"minimum-stability": "dev"？它会覆盖你项目的设置，导致你明明设了 stable，结果还是拉了 dev 版
为什么装包时突然报 “could not find package” 或跳过 RC 版
常见原因是 stability 配置和实际发布状态没对齐。比如你没设 minimum-stability，Composer 默认按 stable 解析，此时如果一个包最新版只是 3.0.0-RC2，它就会直接报错“找不到匹配版本”，而不是退而求其次装 RC。
- 遇到这种报错，先查包的真实发布记录：
composer show vendor/package --all - 确认它最新版确实是 RC？那就得显式降级
minimum-stability到RC（注意大写），再靠prefer-stable防止它退到dev - 某些私有仓库或 GitHub 包未打 tag，只推了分支？那就只能用
dev-main这类写法，且确保minimum-stability是dev或更低
require 里写稳定性标记的几种典型写法
最稳妥的方式永远是在 require 字段里显式声明，而不是只靠全局配置——这样可读性强，也避免误伤其他依赖。
这些写法都合法，但语义和行为差异明显：
-
"vendor/pkg": "^2.0@dev"→ 装 2.x 中任意 dev 分支（如dev-main），不关心是否带版本号 -
"vendor/pkg": "2.0.0-beta1"→ 精确锁定这个 beta 版，不会升级到2.0.0-beta2 -
"vendor/pkg": "dev-feature/x"→ 安装名为feature/x的远程分支（前提是仓库存在该分支） -
"vendor/pkg": "9999999-dev"→ 强制走开发模式，常用于 fork 后本地调试，但要注意这会绕过所有稳定性检查
真正复杂的地方在于：不同包可能各自声明了不同的 minimum-stability，而 Composer 的解析是递归合并的。你看到的最终行为，往往是顶层项目配置、子依赖自身配置、以及你在 require 里写的标记三者共同作用的结果——这点最容易被忽略。
