Composer的包版本稳定性策略：稳定版还是开发版

Composer默认只安装stable版本以保障可靠性，稳定版指正式tag版本，开发版包括RC、beta、alpha和dev；可通过require指定dev版本或设minimum-stability调整全局策略，但生产环境禁用dev。

如果你曾疑惑为什么Composer默认只给你安装那些“正经”的稳定版本，而不是最新的开发分支，那么这里有个核心逻辑需要先搞清楚：这并非一个随意的默认设置，而是Composer保障你项目依赖可靠性的基石。简单说，除非你明确要求，否则它绝不会主动引入那些可能“翻车”的开发版。

什么是稳定版 vs 开发版？

Composer对包的版本有一套清晰的稳定性分级，从高到低依次是：stable、RC（候选发布版）、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）或具体的提交哈希值。这类版本API随时可能变动，没有任何兼容性保证。

如何临时安装一个开发版？

方法其实很直接：在composer.json的require字段里，明确指定开发版的版本约束即可。Composer会为这个包临时放宽稳定性策略。

"require": {
    "monolog/monolog": "dev-main",
    "lara vel/framework": "9.x-dev"
}

不过，这里有个关键细节需要注意：像dev-main这样的分支引用并非语义化版本，因此不会触发Composer的常规版本更新逻辑。每次执行composer update，它都会直接拉取该分支最新的代码，这可能会带来意想不到的变更。

• 使用dev-branch-name比直接用提交哈希更易读，但两者本质上都跳过了版本锁定机制。
• 如果一个开发版的包，其自身又依赖了其他开发版，那么这些间接依赖的稳定性策略也会被连带“降级”。
• 想确认当前安装的是否为开发版？运行composer show monolog/monolog一看便知。

想全局允许 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稳定版，Composer也可能优先安装v2.1.0-beta1。
• 需要警惕的是，在生产环境中，绝对禁止将minimum-stability设置为dev，否则持续集成（CI）流程很可能因为分支的随机变动而构建失败。

为什么 composer require foo/bar:dev-master 有时失败？

这个问题常常让人困惑。明明指定了开发分支，为什么还是装不上？根源往往不在你的本地配置，而在于依赖链的深处。目标包自身的composer.json可能设置了"minimum-stability": "stable"，并且没有声明"prefer-stable": true。这导致它自身的依赖拒绝加载任何非稳定版本，从而让整个安装请求失败。

• 典型的错误信息可能是：Could not find package foo/bar with stability dev。
• 这本质上是依赖图中某一层包锁死了稳定性策略所导致的冲突。
• 解决办法通常是尝试更具体的分支名（如dev-main），或者联系该包的维护者调整其配置。
• 用--ignore-platform-reqs这类参数临时绕过？这通常只是掩盖了问题，并非真正的解决方案。

说到底，安装单个开发版包并不难。真正的挑战在于，当多个包对版本稳定性有着不同甚至冲突的要求时，Composer如何在复杂的依赖图中做出裁决。遇到这种棘手的依赖冲突时，与其反复调整minimum-stability，不如使用composer why-not命令来深入诊断，往往更能直击问题要害。