如何在 Composer 中优雅地处理对 dev-master 的依赖？

推荐避免直接依赖 dev-master，必要时应通过指定 commit hash、设置 minimum-stability 和 prefer-stable、使用 fork 仓库或本地补丁等方式确保可控性与可维护性。

直接依赖 dev-master 不推荐，但有时确实绕不开——比如你正在等某个包的 PR 合并、修复尚未发版，或参与开源协作。关键不是“能不能用”，而是“怎么用得稳、可维护、不坑队友”。

优先用更稳定的替代方案

在伸手要 dev-master 之前，先确认有没有更稳妥的选择：

• 查该包的 GitHub Releases 或 Packagist 版本列表，看是否有带 -dev 后缀的预发布版本（如 v2.5.0-beta1），它们比 dev-master 更可控；
• 用 composer show vendor/package --all 查看所有可用分支和标签，有时 dev-main 或 dev-next 分支语义更明确；
• 如果只是需要某次提交的修复，直接指定 dev-master#commit-hash（如 "vendor/package": "dev-master#abc1234"），避免后续推送破坏兼容性。

锁定分支 + 禁用自动更新

若必须用 dev-master，务必配合 minimum-stability 和 prefer-stable 控制风险：

• 在 composer.json 中显式设置：
  

  "minimum-stability": "dev",<br>"prefer-stable": true

  登录后复制

  —— 这样其他包仍优先装稳定版，仅对明确声明 dev- 的依赖才走开发分支；
• 给该依赖加 @dev 标签（如 "vendor/package": "dev-master as 1.0.x-dev"），既满足版本约束语法，又让 composer update 不轻易升级到不兼容变更；
• 运行 composer update vendor/package --with-dependencies 时加 --no-dev 要谨慎——它可能跳过你依赖的 dev 包，导致安装失败。

用仓库配置精准控制源

当上游主仓库不稳定或你想临时打补丁时，可以 fork 并指向自己的仓库：

标签： composer js git json github ai