Composer通过版本约束和配置控制dev版本安装，默认不安装dev分支以确保稳定性。需在composer.json中调整设置：可显式指定如"dev-main"，但推荐使用@dev标识符或as语法局部允许；设minimum-stability为dev可全局启用但降低安全性，配合prefer-stable能优先选稳定版；当依赖链中存在dev依赖时，应优先更新包或请求维护者发布稳定版，避免全局放宽限制。
Composer 在处理依赖包的 dev 版本时，主要通过版本约束和配置选项来控制是否允许安装开发分支。当你使用的某个包依赖了另一个包的 dev 版本（如 dev-main、dev-develop 等），Composer 默认可能不会安装这些不稳定版本，除非你明确允许。
理解 dev 版本的含义
dev 版本指的是尚未发布为稳定版本的代码分支，通常对应 Git 的开发分支（如 main、master、develop）。这类版本没有语义化版本号（如 1.0.0），而是以 dev- 开头的形式存在。
例如：
dev-maindev-developdev-feature/new-api
这些版本可能随时变更，不适合生产环境直接使用，但有时某些上游包会依赖它们进行快速迭代。
允许安装 dev 版本依赖的方法
如果一个包声明了对另一个包的 dev 版本依赖，你需要在项目根目录的 composer.json 中调整稳定性设置，否则 Composer 会报错并拒绝安装。
以下是几种常用方法：
1. 使用 version constraint 显式指定 dev 分支你可以直接在 require 中引用 dev 版本：
{
"require": {
"some/package": "dev-main"
}
}
但这样会锁定到该 dev 分支，不推荐用于生产。
2. 设置 minimum-stability修改 minimum-stability 字段，允许加载特定稳定级别的包：
{
"minimum-stability": "dev",
"require": {
"some/package": "^1.0"
}
}
这会让 Composer 允许安装 dev、alpha、beta 等不稳定版本。但会影响所有依赖，降低整体稳定性。
如果你设置了 minimum-stability 为 dev，但希望尽可能使用稳定版，可以启用 prefer-stable：
{
"minimum-stability": "dev",
"prefer-stable": true,
"require": {
"some/package": "^1.0"
}
}
这样 Composer 会在满足条件下优先选择稳定版本。
4. 使用 stability flags（推荐方式）最灵活的方式是保持 minimum-stability 为默认值（如 stable），仅对特定包允许 dev 版本：
{
"require": {
"some/package": "^1.0",
"another/package": "dev-main as 1.2.x-dev"
},
"minimum-stability": "stable"
}
或者更清晰地使用稳定性标识符：
{
"require": {
"vendor/package": "1.0.*@dev"
}
}
@dev 表示允许这个包使用开发版本，而其他包仍受稳定性限制。
处理第三方包依赖 dev 版本的情况
当你的依赖 A 依赖于 B 的 dev 版本，但你的项目不允许不稳定包时，会出现冲突。
解决办法包括：
- 检查是否有更新的稳定版 A 已发布，不再依赖 dev 包
- 向 A 的维护者提议发布稳定版本或调整依赖
- 临时允许相关包使用 dev 版本（通过
@dev或调整minimum-stability） - 使用 platform config 或
conflict手动干预依赖解析
基本上就这些。Composer 对 dev 版本的处理很灵活，关键是根据项目需求平衡灵活性与稳定性。不复杂但容易忽略的是：尽量避免全局设为 dev 稳定性，优先用 @dev 或 as 方式局部放开限制。
