dev-master 不是稳定选项，多数情况下不该用；真要尝鲜应优先选具体 dev 分支（如 dev-main）或带 commit hash 的版本约束（如 dev-main#abc1234），以确保可重现性和稳定性。
直接说结论：dev-master 不是稳定选项，多数情况下不该用；真要尝鲜，优先选具体 dev 分支或带 commit hash 的版本约束，而不是无脑 dev-master。
为什么 dev-master 容易出问题
它不是版本号，而是 Composer 对「当前默认分支最新提交」的动态别名。一旦上游仓库改了默认分支（比如从 master 切到 main），或者合入了破坏性变更、未测代码，你的项目就可能当场报错或行为异常。
- CI 构建可能今天成功、明天失败，因为依赖的 commit 已变
-
composer install在不同机器上可能拉到不同代码，违背可重现性原则 - 包作者没发正式版，但你用了
dev-master，等于主动跳过 semver 和测试流程
怎么安全地安装开发版（替代 dev-master）
核心思路：把「动态引用」换成「可锁定的具体目标」。
- 查清目标包的真实开发分支名（常见是
main、develop、next），用dev-main替代dev-master - 更稳妥：用 commit hash 锁定，例如
"vendor/package": "dev-main#abc1234"（hash 需对应一个实际 commit） - 如果包已配置
repositories或支持package类型自定义源，可临时加 Git 地址+分支，但仅限调试
示例命令：
composer require vendor/package:dev-main
composer require vendor/package:dev-main#7f8a1a2
装完之后必须检查的三件事
dev 版本不会触发自动 autoload 重生成或脚本执行，很多问题就卡在这一步。
- 运行
composer dump-autoload，尤其当你发现新类找不到时 - 确认
composer.json里该包的版本约束是否被意外覆盖（比如require-dev里有冲突规则） - 执行
composer show vendor/package，看实际安装的 commit、分支、是否启用了prefer-source
真正麻烦的从来不是装上 dev 包，而是它悄悄引入了不兼容接口、缺失的类型声明、或和你本地 PHP 版本不匹配的语法——这些在 composer require 成功后根本不会报错，只等第一次调用才爆发。
