composer如何设置最小稳定性（minimum-stability）？（dev/stable/beta选择指南）

minimum-stability 是 composer 在无满足约束的 stable 版本时的兜底稳定性策略，非版本优先级开关；设为 dev 会导致意外安装开发版（如 v2.10.0-dev），破坏语义化版本控制。

minimum-stability 是什么，为什么不能随便设成 dev

它不是“版本优先级开关”，而是 Composer 在找不到满足约束的 stable 版本时， fallback 到哪个稳定性级别的兜底策略。设成 dev 后，composer require monolog/monolog 可能直接装 v2.10.0-dev（哪怕 v2.9.0 已发布），因为 dev 匹配度更高——这不是你想要的“最新功能”，而是放弃语义化版本控制。

• 默认值是 stable，意味着只接受 stable、RC、beta 等明确标记为非开发版的包（前提是它们满足 require 的版本约束）
• minimum-stability 不影响你显式指定的版本，比如 "monolog/monolog": "dev-main" 仍会装 dev-main，哪怕全局设了 stable
• 它和 prefer-stable: true 配合才有实际意义：后者让 Composer 在多个候选版本中倾向选更稳定的那个

如何正确设置 minimum-stability（项目级 vs 全局）

永远在项目根目录的 composer.json 里设，别碰全局配置。全局设 dev 是给所有项目埋雷。

• 在 composer.json 的顶层加字段：

  "minimum-stability": "stable"

• 如果项目确实需要某几个包用 beta 版（比如 laravel 11 正式发布前试用），就单独放开：

  "require": {   "laravel/framework": "^11.0@beta",   "symfony/console": "^7.0" }

• 想临时允许 RC 但拒绝 dev？设 "minimum-stability": "RC"，再配合 "prefer-stable": true，否则可能装到 dev 分支

常见错误现象：装了不该装的 dev 版本

典型表现是 composer install 后，vendor/ 里出现 dev- 开头的版本号，或 composer show 显示 dev-main、dev-develop。

• 原因常是：项目没设 minimum-stability，但某个依赖包的 composer.json 里写了 "minimum-stability": "dev"，且你又没在自己的 require 中锁定具体版本
• 检查方式：composer show -s <package-name></package-name> 看它的 stability 标签；composer depends <package-name></package-name> 找出谁把它拉进来的
• 修复不是改全局配置，而是：① 在自己项目的 require 中写死版本（如 "^3.5.0"）；② 或加 @stable 后缀（"monolog/monolog": "^3.0@stable"）

beta/stable/dev 的实际兼容性影响

稳定性标签本质是作者打的“免责声明”。Composer 不验证代码质量，只按标签做筛选。

• stable：作者认为可生产使用，有完整测试和文档，API 冻结。Laravel、Symfony 主线版本都走这条路
• beta：功能完整但可能调接口、修边界 case。适合预研，不适合上线。比如 PHP 8.3 的 beta 版本扩展，可能在 RC 阶段砍掉某个函数
• dev：随时变，没测试保障。常见于 PR 验证分支（dev-fix-login-bug）或每日构建版（dev-main）。CI 跑通不等于你的业务逻辑没问题

最易被忽略的是：某些包把 dev-main 当作“最新版”推给用户，而它的 composer.json 可能依赖另一个尚未 release 的 dev 包，形成隐式依赖链——这时 minimum-stability 就成了唯一刹车片。