dev-master不是版本而是高风险动态别名，因2026年起主流仓库普遍将默认分支从master改为main，Composer解析失败导致“Could not find package”报错。
dev-master 不是版本，而是失效风险极高的动态别名；2026 年起绝大多数主流包已弃用 master 分支，直接写 dev-master 基本等于安装失败。
为什么 dev-master 总报 “Could not find package”
Composer 会尝试解析 dev-master 为远程仓库的 master 分支，但 GitHub 新仓库默认分支已是 main，旧仓库也普遍完成迁移。一旦远程没有 master 分支，Composer 就无法定位，直接报错。
- 运行
git ls-remote --symref https://github.com/vendor/package.git HEAD查真实默认分支名 - 若返回
ref: refs/heads/main，就必须改用dev-main，不是可选项 - 私有 GitLab/Gitee 仓库同理，需确认实际分支名，不能凭经验硬写
dev-master - 即使分支存在，若包未在 Packagist 注册，还需在
repositories中显式声明vcs类型源
composer require vendor/package:dev-main 仍失败？检查这三点
命令行写对了，不代表能装上。常见卡点不在语法，而在 Composer 的稳定性策略和锁文件残留。
- 没加
--stability-dev（或简写-s dev）：默认只搜 stable 包，dev-main被直接跳过 -
composer.lock锁定了旧版本：哪怕composer.json已改，composer install仍按锁文件还原，必须composer update vendor/package或删锁重装 - 项目根
composer.json含"prefer-stable": true：它会压制dev-main，强制 fallback 到最近 stable tag（如v2.3.0），得配"prefer-stable": false
怎么让 dev-main 真正稳定、可复现
不锁定具体提交的 dev-main 和 dev-master 一样危险——每次 composer update 都可能拉下不同代码，CI 构建不可重现。
- 优先用
dev-main#abc1234：把分支名和 Git 短哈希拼在一起，abc1234必须是该分支上真实存在的 commit - 若需参与协作开发，用
"dev-main as 999.999.999"：这个虚拟高版本号确保依赖解析时不会被其他 stable 版本覆盖 - 装完立刻执行
composer show vendor/package，确认输出中的source是git类型、reference是你指定的哈希，而非dist或模糊的dev-main - 避免在生产环境或 CI 配置中直接写
dev-main—— 它没有测试保障，也没有语义化约束
真正麻烦的不是装不上，而是装上了却没意识到：类自动加载路径可能已变、PHP 最低版本要求可能升了、甚至某个方法已被静默移除。这些都不会在 composer require 时报错，只等第一次调用才崩。
