Composer默认只安装stable版本，遇dev-master/alpha/beta等会报“Could not find package”；需加@dev后缀、设minimum-stability或用composer show确认版本存在。
composer install dev-master 或 alpha/beta 版本时提示“Could not find package”
默认情况下，composer 只允许安装 stable（稳定）版本的包，遇到 dev-master、alpha、beta、rc 等预览/开发版会直接跳过或报错。这不是网络或仓库问题，而是稳定性约束生效了。
- 检查包是否存在对应分支或版本：用
composer show vendor/package --all查看可用版本列表，确认dev-master或v2.0.0-beta1确实存在 - 临时安装单个开发版：在
require时显式指定版本，并加@dev后缀，例如：composer require monolog/monolog:dev-main@dev - 若仍失败，说明该分支未被 Packagist 索引，需确认是否为私有包或未提交到主仓库
设置 minimum-stability 全局或项目级策略
minimum-stability 是 composer.json 中控制“默认接受最低稳定性级别”的配置项，它不决定能否安装某个具体版本，而是影响版本约束解析时的默认筛选行为。
- 可选值（从高到低）：
stable→RC→beta→alpha→dev - 设为
"minimum-stability": "dev"后，"monolog/monolog": "^2.0"这类约束就可能匹配到dev-main，而非仅v2.0.1 - 该设置作用于整个项目，但可被每个包的版本约束覆盖：比如即使全局是
stable，仍可通过"monolog/monolog": "dev-main@dev"单独拉取开发版
{
"minimum-stability": "beta",
"prefer-stable": true,
"require": {
"laravel/framework": "^10.0"
}
}
注意：prefer-stable: true 表示“在满足 minimum-stability 前提下，优先选 stable 版”，能避免意外装到 dev 分支。
require 时用 stability flags 覆盖默认行为
比改 minimum-stability 更安全的做法，是在 require 命令中直接带稳定性标记，只影响当前包，不污染项目策略。
-
composer require vendor/package:dev-main—— 拉取main分支最新提交（等价于dev-main@dev） -
composer require vendor/package:v2.0.0-rc1—— 明确指定 RC 版本 -
composer require vendor/package:dev-feature/x@dev—— 拉取特定功能分支（需该分支已 push 到远程） - 如果命令报
Could not resolve dependency，大概率是没加@dev后缀，或分支名拼写错误（如写成dev-master但实际是dev-main）
私有包或 GitHub 直链依赖怎么处理稳定性？
从 GitHub URL 直接 require（如 "vendor/name": "dev-main#commit-hash"）时，minimum-stability 不起作用，必须显式加 @dev，否则 Composer 会拒绝解析。
- 正确写法：
"myorg/mylib": "dev-main#abc123@dev" - 错误写法：
"myorg/mylib": "dev-main#abc123"→ 报错 “Your requirements could not be resolved” - Git 仓库需在
composer.json中声明version字段（如"version": "dev-main"），否则 Composer 无法识别其稳定性 - 若使用
pathrepository 类型本地链接，同样要加@dev，否则会因无版本号而失败
稳定性不是“要不要装”，而是“认不认这个版本”。很多问题其实卡在 @dev 忘写了，或者分支名和远程实际名称对不上——建议先 git ls-remote 确认远端分支名再操作。
