dev-master 不符合生产环境确定性要求，因其无固定版本号、不可追溯、易引发不一致构建与运行时错误，应改用 commit hash 或语义化版本锁定。
dev-master 版本没有稳定语义化版本号
Composer 的 dev-master 指向 Git 仓库当前 master（或默认）分支的最新提交，它不对应任何 v1.2.3 这类语义化版本。这意味着每次运行 composer install 或 composer update，只要远程分支有新提交，就可能拉取到完全不同的代码——哪怕只是修复了一个拼写错误，也可能意外引入未测试的接口变更或行为改动。
常见错误现象包括：
- CI 构建通过，生产环境部署后接口 500（因某次
dev-master提交删了旧方法但没改调用方） -
composer.lock在不同机器上生成不一致的哈希，导致依赖“看似相同实则不同” - 无法回滚：你记不住某次上线对应的 commit hash，
dev-master本身不是可追溯的版本标识
无法保证可重复构建和安全审计
生产环境要求每次部署都基于确定、可验证的代码快照。dev-master 天然违背这一原则：它没有固定 SHA，不能被 SCA（软件成分分析）工具识别，也无法纳入 SBOM（软件物料清单）管理。
使用场景中必须规避的情况：
- 金融、医疗等强合规场景：审计时无法提供所用组件的确切版本与来源
- 团队协作：开发用
dev-master调试，但 QA 和运维拿到的是另一时刻的dev-master，问题无法复现 - 私有包未发版时临时引用：应改用
dev-feature/xxx#commit-hash或发布带版本号的 alpha/beta
composer.json 中误配 dev-master 的典型表现
很多人以为加了 "minimum-stability": "dev" 就“可控”，其实这只是放宽约束，不解决根本问题。真正危险的是在 require 中直接写：
{
"require": {
"monolog/monolog": "dev-master"
},
"minimum-stability": "dev"
}
这等价于告诉 Composer：“我接受任意一次未经过 tag 验证的提交”。更隐蔽的问题是：
- 某些包的
dev-master可能已废弃 PHP 7.x，而你的生产环境还在跑 7.4 —— composer 不报错，但运行时报ParseError - 依赖树中某间接依赖用了
dev-master，你根本没在composer.json里声明，却在生产环境突然失效 -
composer update --with-dependencies会连带升级所有dev-*分支，范围不可控
替代方案：用 commit hash 或真实版本号锁定
如果确实需要某个尚未发版的功能，优先选择明确、可锁定的方式：
- 用完整 commit hash 替代
dev-master："vendor/package": "dev-main#abc1234"（注意：分支名可能是main） - 要求上游发布
dev稳定性版本，如2.5.x-dev，它仍受minimum-stability控制，且能被composer.lock精确记录 - 私有包场景下，本地打
git tag v1.0.0-rc1并git push --tags，然后直接 require"vendor/private": "^1.0.0-rc1"
commit hash 看似麻烦，但它让每一次依赖变更都变成显式、可审查、可 bisect 的操作。生产环境里，模糊的“最新”从来不是优势，确定性才是底线。
