为什么Composer在生产环境不建议使用dev-master版本？

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 的操作。生产环境里，模糊的“最新”从来不是优势，确定性才是底线。