Composer 的 stability flags 是附加在包名或版本约束后的修饰符，用于显式指定包的稳定性级别，如 @dev、@alpha、@beta 等，覆盖默认仅安装 stable 版本的策略。
Composer 的 stability flags 是什么？
它们是 Composer 用来控制包版本“稳定性级别”的显式标记，不是版本号本身的一部分，而是附加在包名或版本约束后的修饰符。Composer 默认只安装 stable（即无 flag 或带 @stable）的版本，遇到 @dev、@alpha 等会直接跳过——除非你明确允许。
为什么加 @dev / @alpha / @beta 后能装上本来装不了的包？
因为这些 flag 实际上覆盖了 Composer 的默认稳定性策略。比如 monolog/monolog:2.10.0@dev 并不表示“2.10.0 是 dev 版”，而是告诉 Composer：“我接受这个包在 2.10.0 这个 commit（或分支）上的开发态快照”，哪怕它根本没打过 tag。
-
@dev：指向分支（如dev-main）或某次 commit，不保证 API 稳定，可能随时变 -
@alpha/@beta：对应带 alpha/beta 标签的正式 release（如v3.0.0-alpha1），语义化版本中已声明不稳定阶段 -
@RC（Release Candidate）和@stable也属同类机制，但后者通常省略不写
使用时必须配 "minimum-stability" 或 "prefer-stable" 吗？
不一定，但强烈建议配。单独写 "monolog/monolog:@dev" 可能失败，因为根 composer.json 的 "minimum-stability" 仍是默认的 stable，它会压制所有低于 stable 的请求。
正确做法是二者配合：
{
"require": {
"monolog/monolog": "3.0.0@beta"
},
"minimum-stability": "beta",
"prefer-stable": true
}
-
minimum-stability设定全局下限（devalpha beta RC stable） -
prefer-stable: true表示“在满足minimum-stability前提下，优先选 stable 版”，避免整项目被拖进不稳定状态 - 直接在 require 中用 flag（如
@beta）只影响那个包，不改全局策略
常见踩坑点
最典型的是误以为 @dev 能“降级”到旧版开发分支——其实它只认当前分支 HEAD 或指定 commit，跟版本号无关。例如 "vendor/package:1.2.0@dev" 是非法写法，Composer 会报错 Could not parse version constraint。
- flag 必须紧跟在版本约束之后，中间不能有空格：
"foo/bar:dev-main@dev"✅，"foo/bar:dev-main @dev"❌ -
@dev指向分支时，分支名要完整，dev-master已废弃，现在多用dev-main - 私有仓库若未配置
repositories类型为vcs，加 flag 也没用——Composer 根本拉不到源 - CI 环境中若未设
COMPOSER_MEMORY_LIMIT=-1，高频率切@dev分支可能触发内存溢出
真正难的不是语法，而是判断哪个 flag 匹配你的实际需求：是要验证某个 PR 的改动（用 @dev + commit-hash），还是试用官方发布的预发布功能（用 @beta）——混用会导致依赖锁定混乱，且难以复现。
