dev-master 指 master 分支最新 HEAD 提交，每次 composer update 可能拉取不同代码，导致环境不一致、CI 难复现、分支改名后失效；仅限 PR 验证或急需未发版修复时使用，推荐锁定具体 SHA 或改用 dev-main。
dev-master 不是稳定版本，直接写在 composer.json 里等于主动接受随时可能崩掉的代码。
dev-master 到底指哪个提交？
它不是某个固定快照，而是当前 master 分支最新的 HEAD 提交 —— 每次 composer update 都可能拉下不同代码，连哈希都不可控。
- 没有语义化版本约束，
composer install在不同机器上可能装出不一致的结果 - CI/CD 构建失败时很难复现，因为错误可能只存在于某次临时提交中
- GitHub 上
master改名成main后，有些包的dev-master实际指向已失效（Composer 会 fallback 到默认分支，但行为不透明）
什么时候真得用 dev-master？
仅限两种情况：你正在给某个包提 PR，且需要本地验证补丁；或该包长期没发版，而你急需某个刚合入 master 的修复。
- 优先尝试用
dev-main（如果对方主分支叫main） - 更稳妥的做法是锁定具体提交：
"vendor/package": "dev-main#abc1234"，其中abc1234是 Git SHA 前 7 位 - 若必须用
dev-master，务必在composer.json加上"minimum-stability": "dev"和"prefer-stable": false，否则 Composer 会直接忽略
composer require dev-master 的常见翻车点
运行 composer require vendor/package:dev-master 看似简单，实际常因依赖冲突静默失败。
- 报错
Your requirements could not be resolved to an installable set of packages.？大概率是dev-master依赖了更高版本的 PHP 或其他包，而你环境不满足 - 没报错但装的是旧版？检查是否被
composer.lock锁定 —— 先删锁文件再试，或加--no-cache - 装完发现类找不到？可能是包启用了 PSR-4 自动加载但
composer.json里路径写死了src/，而dev-master已迁到lib/
用 dev-master 就得接受「今天能跑，明天 CI 报红」的风险。真正省事的方式，是盯住包的 issue 区，等它发个带版本号的 release —— 那才是 Composer 设计想让你用的东西。
