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