minimum-stability 控制 Composer 在未显式指定版本约束时默认允许安装的包稳定性级别，按 dev、alpha、beta、rc、stable 从低到高排序，影响自动选择带稳定性标识的预发布版本。
Composer 的 minimum-stability 决定了项目允许安装的包版本稳定性级别，默认是 stable。它不是“越稳定越好”，而是要和你的项目阶段、依赖策略、上线要求匹配——设得太严会装不上新功能，太松又容易引入不稳定的代码。
minimum-stability 控制什么？
它限制 Composer 在没有显式指定版本约束（如 "monolog/monolog": "^2.0@beta"）时，自动选择哪些预发布版本。只要包的版本号带稳定性标识（比如 v3.0.0-beta1、v2.8.0-rc2），就受此配置约束。
注意：它不强制所有依赖都降级到某个稳定性，只是设下“默认门槛”。你仍可通过在 require 中加 @dev、@alpha 等后缀，为单个包绕过该限制。
各稳定性级别的实际含义与风险
Composer 按以下顺序从低到高定义稳定性（越靠前越不稳定）：
-
dev：对应
dev-main、dev-develop这类开发分支，可能随时重写、无测试、无文档，仅适合本地实验或深度参与开源贡献 -
dev（补充说明）：即使写成
"minimum-stability": "dev"，Composer 也不会自动装dev-*分支——除非你在require中明确写"vendor/pkg": "dev-main" - alpha：功能雏形已实现，但 API、数据库结构、配置格式都可能大改；通常无完整测试覆盖，不建议用于任何非沙箱环境
- beta：核心功能完成，API 基本冻结，开始集成测试；仍可能存在严重 bug 或性能问题，可小范围试用
- rc（Release Candidate）：候选发布版，目标是正式版 v1.0.0；除极少数临界 bug 外不应再改动；适合预上线验证
- stable（默认）：通过全部测试、有文档、有长期支持承诺的正式版本；生产环境唯一推荐选项
怎么合理设置？看场景选值
别全局一刀切。根据项目所处阶段和用途灵活调整：
- 新项目快速原型阶段 → 设为
beta，方便接入主流组件的最新特性（如 Laravel 11、Symfony 7 的 beta 版） - 内部管理后台 / 内网工具 → 可设为
rc，享受新功能同时规避 alpha/beta 的不确定性 - 对外 SaaS 服务或金融类系统 → 必须保持
stable，并配合"prefer-stable": true防止意外拉到 rc - 想临时测试某包的 dev 分支 → 不改
minimum-stability，只在 require 中加@dev，例如："phpunit/phpunit": "dev-main@dev"
搭配 prefer-stable 才真正可控
minimum-stability 单独用容易误伤：比如设成 beta，Composer 可能优先装 v2.5.0-beta3 而不是已发布的 v2.4.0（stable）。这时要启用：
"prefer-stable": true
它的作用是：当存在同一大版本的 stable 版时，优先选 stable，仅在 stable 不可用时才退而求其次（比如你要 ^2.5，但只有 2.5.0-beta1 和 2.4.3，就会装 2.4.3）。
强烈建议：只要不是明确需要预发布版，就把 prefer-stable 设为 true，和 minimum-stability 形成双重保险。
