minimum-stability 是 composer 对未显式声明稳定性标签的依赖所设的全局稳定性准入门槛，取值越低（如 dev）允许安装越不稳定的版本，但 RC 因语义优先级高于 beta 而不被 “beta” 值自动包含。
minimum-stability 是什么，它到底控制什么
minimum-stability 不是“最低稳定版本号”，而是 Composer 对包版本稳定性标签（如 stable、beta、dev）的全局准入门槛。它只影响那些**未显式声明 stability 标签**的依赖声明。比如你写 "monolog/monolog": "^2.0"，没带 @dev 或 @beta，这时才由 minimum-stability 决定能否安装 2.1.0-beta1 这类预发布版本。
常见取值与实际行为差异
可选值为 stable、RC、beta、alpha、dev，越靠后允许的版本越“不稳”。但注意：
-
"minimum-stability": "beta"允许安装beta、alpha、dev版本，但不自动允许RC—— 因为RC在语义上比beta更接近稳定，Composer 按字母序（alpha -
"minimum-stability": "stable"是默认值，但只要某条 require 显式写了@dev，比如"vendor/pkg": "dev-main"，该行仍会生效，不受此配置限制 - 该字段**不改变已锁定的
composer.lock行为**：如果 lock 文件里已有dev-master，即使你把minimum-stability改成stable并运行composer update，它也不会自动降级——除非你加--with-all-dependencies或删 lock 重装
如何安全地临时放宽 stability 要求
多数时候你不需要全局改 minimum-stability，尤其在生产项目中。更稳妥的做法是：
- 对单个包显式指定稳定性，例如：
"phpunit/phpunit": "^9.5@beta" - 用
prefer-stable: true配合minimum-stability: dev：这样 Composer 优先选稳定版，仅在无稳定版可选时才退而求其次，避免意外装入大量dev包 - 开发阶段可在命令行临时覆盖：
composer require vendor/pkg:dev-feature-branch --stability=dev，无需改composer.json
容易被忽略的陷阱：require-dev 和平台包
minimum-stability 同样作用于 require-dev 下的包，这点常被忽视。如果你设了 "minimum-stability": "alpha"，而 phpunit 的某个 alpha 版本有严重 bug，所有 composer install 都可能失败。
另一个盲区是平台包（如 ext-gd、php）。它们没有 stability 标签，因此 minimum-stability 完全不约束它们——你得靠 config.platform 或 platform-check: false 来管理 PHP 扩展兼容性。
真正麻烦的是混合场景：一个包自身是 stable，但它依赖的子依赖声明了 "monolog/monolog": "^3.0@dev"，此时即使你的 minimum-stability 是 stable，也会因传递依赖被拉入不稳定版本——Composer 不校验依赖树中每一层的 stability 声明是否符合你的全局设置。