直接加@dev比设minimum-stability更安全，因前者仅限当前包，后者影响所有依赖；需用as别名使dev-main参与语义化约束；私有仓库须先配置repositories；alpha包无稳定锚点，升级需手动且测试要全面。
想装 dev-main、@beta 或 @alpha 版本，别改全局 minimum-stability —— 直接用 @ 后缀最安全、最可控。
为什么直接加 @dev 比设 "minimum-stability": "dev" 更靠谱
改 minimum-stability 是全局开关，会影响所有依赖包，哪怕你只想要一个包走开发分支，其他包也可能被意外降级成 dev 或 beta。而 @dev 只作用于当前包，Composer 会临时放宽它的稳定性要求，不碰别的包。
-
composer require vendor/package:@dev→ 自动匹配dev-main（不是dev-master，更现代） -
composer require vendor/package:2.0.0-beta1→ 显式指定预发布版本，不依赖minimum-stability - 如果包没打
beta标签，只打了v2.0.0-beta1tag，就得写全："vendor/package": "2.0.0-beta1" - 执行后务必运行
composer show vendor/package，确认versions行真列出了你要的分支或 tag
dev-main as X.Y.Z 别名写法适合长期协作场景
当你在团队里长期依赖某个主分支，又希望它能参与语义化版本约束（比如被其他包用 ^2.0 引用），就得用 as 别名把开发分支“伪装”成一个高版本号。
- 在
composer.json的require里写："vendor/package": "dev-main as 999.999.999" - 这个
999.999.999不是真实版本，只是告诉 Composer：“它比所有正式版都新”，避免被^2.0这类约束跳过 - 不用配
minimum-stability，也不用开prefer-stable: false，干净利落 - 注意：别名只影响版本解析，不改变实际拉取的代码来源（仍是
dev-main分支）
GitHub 上还没发版的包，得先加 VCS 仓库
如果包只存在于 GitHub 仓库、没提交到 Packagist，composer require vendor/package:@dev 会失败 —— Composer 根本找不到这个包名。
- 必须先在
composer.json的repositories段手动注册：
"repositories": [
{
"type": "vcs",
"url": "https://github.com/vendor/package"
}
]
require，例如：composer require vendor/package:dev-main
git@github.com:...），需提前配置 SSH key，否则 clone 会卡住dev-main 必须真实存在且可访问Alpha 包最难搞的不是安装，而是后续升级和维护
装上 @alpha 很容易，但真正麻烦的是：它没有稳定锚点，^3.0 这类约束基本失效，composer update 不会自动拉新，composer.lock 里锁死的是 commit hash，不是版本号。
- 想升级 alpha 包，只能手动
composer update vendor/package，不能靠update --with-dependencies - 依赖链里只要有一个包声明了
"monolog/monolog": "^2.0"，而它的2.x分支压根没发过 alpha，那你的 alpha 配置就白设 - Alpha 包往往缺乏完整测试覆盖，上线前务必验证其行为是否与文档一致，尤其关注异常路径和边界 case
