minimum-stability 是 composer 全局稳定性筛选阈值，默认 stable，仅考虑不低于该稳定性的版本；可为单个包覆盖，prefer-stable 能在低稳定性下优先选同范围最稳版；生产环境必须设为 stable 以确保一致性。
minimum-stability 决定 Composer 默认接受哪些版本稳定性标签
它不是“最低允许版本”，而是“默认只考虑不低于该稳定性的包”。Composer 会把每个包的版本打上稳定性标签（stable、RC、beta、alpha、dev），minimum-stability 就是这条筛选线。默认值是 stable，所以即使某包发布了 v2.0.0-beta.3，只要没发正式 stable 版，就不会被选中——哪怕你 require 的是 "vendor/pkg": "^2.0"。
设为 beta 后，^1.0 可能装到 1.9.0-beta.1
这常被误认为“升级了”，其实是稳定性放宽导致匹配范围扩大。关键点：
-
minimum-stability是全局开关，影响所有未显式标注稳定性的依赖 - 你可以对单个包覆盖它，比如：
"vendor/pkg": "dev-main as 1.0.0"或"vendor/pkg": "2.0.0-RC1" - 如果包本身没有
beta标签的版本，设成beta也装不到——它只是放宽门槛，不创造版本 -
prefer-stable: true可以在minimum-stability较低时，优先选同范围内最稳定的版本（例如有1.0.0和1.0.0-beta.2，仍选前者）
常见错误：require 中写 "dev-master" 却忽略 stability 配置
这种写法明确要求开发分支，但若 minimum-stability 是 stable，Composer 会报错：
Could not find package vendor/pkg with stability stable.解决方式只有两个：
- 把
minimum-stability改成dev（不推荐，影响全部依赖） - 保留
minimum-stability为stable，改用带稳定性后缀的写法："vendor/pkg": "dev-main as 1.0.x-dev" - 或在
require中直接指定带标签的开发版："vendor/pkg": "dev-feature/login#abc123"
生产环境必须锁死 minimum-stability 为 stable
哪怕你本地开发用了 beta 测试新功能，composer.json 中也不该留着 "minimum-stability": "beta" 上生产。原因很实际：
- CI/CD 构建时可能拉到不同时间点的
beta版，行为不一致 - 某天上游突然发了个
2.0.0-beta.5，你的composer update就可能悄无声息切过去 -
composer.lock虽然锁定具体 commit，但minimum-stability影响的是“哪些版本有资格进 lock 文件”，它本身不是锁定项
真正该进 composer.lock 的，是最终解析出的具体版本号和哈希，而不是靠一个全局稳定性阈值去赌。