minimum-stability 是 composer 对包发布状态的信任阈值，非最低版本要求；设为 stable 时会拒绝 dev、beta、rc 等非正式版本，导致显式指定的 dev-main 等安装失败。
minimum-stability 是什么，为什么它总导致安装失败
它不是“最低版本要求”，而是 Composer 对包发布状态的**信任阈值**。设成 stable 时，dev-main、beta、RC 这类非正式版本全被拦在外面——哪怕你明确 require 了 "monolog/monolog": "dev-main"，也会报错 Your requirements could not be resolved。
常见错误现象：
- 执行
composer require some/package:dev-feature却提示找不到包 - 明明 packagist.org 上显示有
v2.0.0-beta1，composer install却只装到v1.9.0 -
composer create-project失败，错误里带could not be found in any version
怎么改？改哪里？优先级顺序必须搞清
配置生效顺序是：命令行参数 > composer.json（当前项目） > COMPOSER_HOME/config.json（全局）> 默认值 stable。别一上来就改全局——多数问题只需局部调整。
实操建议：
- 临时绕过：加
--stability=dev参数，比如composer require vendor/pkg:dev-main --stability=dev - 项目级修改：在项目根目录
composer.json的顶层加"minimum-stability": "dev"，再加"prefer-stable": true（推荐组合，既允许 dev 版本，又优先选 stable） - 别单独写
"minimum-stability": "dev"后不加"prefer-stable": true，否则所有依赖都可能降级到dev-master，CI 构建极不稳定
stable / RC / beta / alpha / dev 这几个值到底啥区别
不是“越靠后越新”，而是“越靠后越不可靠”。Composer 按这个顺序判断是否达标：
stable RC beta alpha dev
举例说明：
-
"minimum-stability": "beta"→ 允许beta、RC、stable，但拒绝alpha和dev -
"minimum-stability": "RC"→ 允许RC和stable，但拒绝beta及更低 -
dev是兜底值，代表接受任何分支、任何提交哈希，适合本地开发，绝不该出现在生产环境composer.json中
为什么有些包加了 stability flag 还是装不上
因为 minimum-stability 只管“默认行为”，不覆盖显式声明。比如你在 composer.json 里写：
"require": {
"some/pkg": "dev-fix-branch"
}那即使
minimum-stability 是 stable，也得配合 "stability-flags": {"some/pkg": "dev"} 才行。
容易踩的坑：
-
stability-flags是 per-package 的，不能写"*": "dev"（语法错误） - 如果包本身没打
dev-标签，只靠分支名（如main）是不够的，得确认它的composer.json里"version"字段或 VCS 仓库实际有对应分支 - 私有 GitLab/GitHub 包若用
type: "package"手动定义，必须显式写"stability": "dev"，minimum-stability对它无效
真正麻烦的从来不是配哪个值，而是搞清哪一层配置在起作用、哪一层被覆盖了。多看 composer show -s 输出里的 stability 列，比猜强得多。
