minimum-stability 越低越危险，它控制Composer默认接受的稳定性级别，设为dev可能导致自动安装不稳定的dev-main版本引发线上故障；合法值按严格度排序为stable、RC、beta、alpha、dev，且需配合prefer-stable:true使用才安全。
直接说结论： minimum-stability 不是“越低越灵活”，而是“越低越危险”——它控制的是 Composer 默认接受哪些稳定性标签（如 dev、beta、alpha）的包，设成 dev 后，哪怕你没显式要求，Composer 也可能自动装一个不稳定的 dev-main 版本，导致线上炸锅。
为什么 minimum-stability 经常被误配
很多人以为设成 dev 就能“随便装包”，结果发现依赖更新后项目突然报错、测试失败、CI 卡住。根本原因是：minimum-stability 是全局兜底策略，不是按需开关——它影响所有未显式声明稳定性的 require 行为。
- 当你写
"monolog/monolog": "^2.0"，但 monolog 的2.10.0是stable，而2.11.0-beta1是beta，如果minimum-stability是beta，Composer 就可能选后者（即使你根本没想要 beta） -
require-dev下的包也受它约束，比如你 dev 时用了"phpunit/phpunit": "^9"，结果装了9.6.0-RC，本地跑通，CI 却因 RC 版本行为差异挂掉 - 它和
prefer-stable是一对组合键：单独调低minimum-stability不安全，必须配合prefer-stable: true才能“允许不稳定但优先稳”
minimum-stability 的合法值和实际效果
它的取值只有五个（大小写敏感），从最严到最松依次是：stable → RC → beta → alpha → dev。注意：RC 不是 rc，小写会报错。
-
"minimum-stability": "stable"：只接受带stable标签或无标签（默认视为 stable）的版本；这是新项目的推荐起点 -
"minimum-stability": "beta"：允许beta、alpha、dev，但不会主动选它们——除非没有满足条件的 stable 版本 -
"minimum-stability": "dev"：连dev-main都能进锁文件，风险极高；仅适合本地快速原型验证，绝不能出现在生产环境composer.json - 所有值都只影响“未指定稳定性”的依赖；若某行写了
"monolog/monolog": "dev-main"，那minimum-stability完全不管它
怎么改才不踩坑：三步实操建议
别直接改根配置，先看当前项目真实依赖情况。用 composer show --all 查哪些包实际装了非 stable 版本，再针对性处理。
- 想临时装一个 dev 包？用
composer require vendor/package:dev-main，而不是调低minimum-stability - 要长期用某个 beta 功能？在 require 行末尾加稳定性后缀，例如：
"symfony/console": "^6.4@beta"，这样既明确又隔离 - 团队协作时，务必在
composer.json里显式写上"prefer-stable": true，否则minimum-stability设再高，也可能因 packagist 元数据混乱拉下不稳定版 - CI 流水线中，建议加检查：
composer validate --no-check-all确保锁文件里没混入dev-或-beta版本号
真正难的不是设哪个值，而是判断“这个包到底有没有 stable 版本可用”——有时候你以为它没，其实是 packagist 缓存延迟，或者作者忘了打 stable tag。遇到这种，宁可 fork + 打 tag，也别无脑开 dev。
