Composer默认只安装stable版本以保障可靠性，稳定版指正式tag版本，开发版包括RC、beta、alpha和dev；可通过require指定dev版本或设minimum-stability调整全局策略，但生产环境禁用dev。
Composer 默认只安装稳定版本的包，除非你明确要求开发版——这是它保障项目可靠性的底层逻辑，不是可有可无的配置项。
什么是稳定版 vs 开发版？
Composer 把版本分为 stable、RC（Release Candidate）、beta、alpha 和 dev 五类，按稳定性从高到低排序。默认只接受 stable；其他都算“不稳定”，需显式启用。
-
stable：打了正式 tag 的版本，如v2.5.0或2.5.0 -
RC/beta/alpha：带后缀的预发布版本，如3.0.0-RC1、2.4.0-beta2 -
dev：分支名（如dev-main）或提交哈希（如dev-feat/logging），不保证 API 兼容性
如何临时安装一个开发版？
直接在 require 中写明版本约束即可，Composer 会自动放宽策略：
"require": {
"monolog/monolog": "dev-main",
"laravel/framework": "9.x-dev"
}
注意：dev-main 不是语义化版本，不会触发自动更新；每次 composer update 都会拉取该分支最新 HEAD，可能引入意外变更。
- 用
dev-branch-name比用dev-commit-hash更易读，但两者都跳过版本锁定 - 若依赖的 dev 包又依赖其他 dev 包，那些间接依赖也会被降级为不稳定策略
-
composer show monolog/monolog可确认当前安装的是dev还是stable版本
想全局允许 beta/RC 怎么办？
修改 composer.json 的 minimum-stability 字段，并用 prefer-stable 平衡风险：
{
"minimum-stability": "beta",
"prefer-stable": true
}
这表示：只要存在 stable 版本就优先选它；否则退而求其次选 beta 或更高（RC、alpha）——但绝不会选 dev。
-
minimum-stability是项目级开关，影响所有依赖 -
prefer-stable: true很关键：否则哪怕有v2.0.0，也会装v2.1.0-beta1 - 生产环境严禁设
"minimum-stability": "dev"，CI 构建可能因分支变动失败
为什么 composer require foo/bar:dev-master 有时失败？
因为目标包的 composer.json 可能设置了 "minimum-stability": "stable"，且没声明 "prefer-stable": true，导致其自身依赖拒绝加载任何非 stable 版本。
- 错误现象常为：
Could not find package foo/bar with stability dev - 本质是依赖图中某层包锁死了稳定性策略，不是你本地配置问题
- 解决方式：改用更具体的分支名（如
dev-main），或联系包作者调整其composer.json - 临时绕过：加
--ignore-platform-reqs不解决问题，只会掩盖依赖冲突
真正难处理的从来不是“怎么装开发版”，而是当多个包对稳定性有不同诉求时，Composer 如何在依赖图里做一致性裁决——这时候看 composer why-not 比反复改 minimum-stability 更有效。
