Composer中的 “stability flags” 是什么意思？ (@dev, @alpha, @beta)

composer 的 stability flags 是附加在包名或版本约束后的修饰符，用于显式指定包的稳定性级别，如 @dev、@alpha、@beta 等，覆盖默认仅安装 stable 版本的策略。

为什么加 @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 设定全局下限（dev alpha 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）——混用会导致依赖锁定混乱，且难以复现。