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 就成了唯一刹车片。
