dev-master 是 Git 默认分支的最新提交，非稳定版，无版本约束和测试保障；应优先使用具体 commit hash 或 dev-main 等明确分支别名，并避免在生产环境使用。
dev-master 不是稳定版本，不能直接当正式依赖用；它代表 Git 仓库默认分支的最新提交，随时可能破坏兼容性或根本跑不起来。
dev-master 是什么，为什么它不是“最新稳定版”
Composer 里的 dev-master 指的是包仓库（通常是 GitHub）上默认分支（如 main 或 master）的当前 HEAD 提交，不经过任何版本标签过滤。它没有语义化版本约束，也没有自动测试保障。
- 不是
v2.3.0那种发布过的正式版，也不等价于 “最新功能版”——可能含未修复的 bug、API 变更、甚至语法错误 - Composer 默认会跳过
dev-前缀的包，除非显式允许：需要在composer.json中设置"minimum-stability": "dev"，且通常还得加"prefer-stable": true来避免意外拉取其他 dev 包 - 很多包已弃用
master分支名，改用main，但dev-master仍会尝试找master，找不到就报Could not find package ... at version dev-master
想装开发版，优先用更明确的 commit-ref 或分支别名
比起模糊的 dev-master，直接指定具体提交或带版本约束的分支更可控：
- 用 commit hash 安装：在
require中写"vendor/package": "dev-main#abc1234"（main是分支名，abc1234是短哈希） - 用分支别名替代
dev-master：如果包主维护了dev-main别名，可写"vendor/package": "dev-main"，比dev-master更准确 - 临时覆盖稳定性：只对单个包放宽限制，不用改全局
minimum-stability，写成"vendor/package": "dev-main as 9.99.99"，把开发版“伪装”成一个虚拟高版本，避免影响其他依赖
运行时常见报错和绕过方式
执行 composer require vendor/package:dev-master 时容易卡住或失败：
-
Could not find a matching version of package vendor/package：大概率是仓库已删master分支，改用main，应改用dev-main -
Root composer.json requires vendor/package == dev-master, found vendor/package[dev-main] but it does not match the constraint：说明包只有dev-main，但你写了dev-master，必须严格匹配分支名 - 安装后
vendor/autoload.php加载失败或类找不到：开发版可能重构了命名空间或移除了旧类，别假设接口不变 - CI 构建失败：因
dev-版本不被缓存、每次 resolve 结果可能不同，严禁在生产 CI 中固定使用dev-master
真要试开发版，务必隔离环境
本地验证可以，但不能进 git commit 或共享 lock 文件：
- 先
git checkout -b try-dev-version新分支，避免污染主流程 - 运行
composer require vendor/package:dev-main --no-update先写入composer.json，再composer update vendor/package --with-dependencies精准更新该包及其直连依赖 - 装完立刻跑
composer show vendor/package确认实际安装的 commit hash，并记下来（比如dev-main abc12345），后续复现或回滚靠它，而不是靠dev-master这种飘忽的指针 - 如果项目用 Docker，别把
dev-包打进基础镜像——构建时网络抖动或源仓库变更都可能导致镜像不可重现
dev-master 的最大陷阱，是让人误以为“用了最新代码=更可靠”，其实它恰恰是最不可靠的引用方式。真正需要开发版时，commit hash 和分支+hash 组合才是能落地的最小安全单元。
