应使用完整40位SHA1哈希值加dev分支名（如dev-main#7f8c...）并配置minimum-stability=dev、--prefer-source，再通过composer.lock的source.reference和git rev-parse验证。
如何用 Composer 安装指定 commit 的 dev-master 版本
直接写 "package-name": "dev-master#abc1234" 就行，但很多人卡在 hash 写错、分支名混淆或未启用 minimum-stability 配置上。
-
dev-master不是稳定版本，必须显式允许非稳定依赖，否则 Composer 会跳过或报错 - commit hash 必须是目标仓库中真实存在的完整 40 位 SHA1（如
7f8c4d9a2e1b3c4d5e6f7a8b9c0d1e2f3a4b5c6d），缩写（如abc1234）仅在某些 Git 配置下生效，CI 或干净环境里大概率失败 - 如果包的
composer.json中定义了default-branch（如"main"），而你仍写dev-master，可能拉不到最新代码——因为 master 分支已废弃，实际应改用dev-main#xxx
为什么 composer require vendor/package:dev-master 失败或装错版本
常见现象是最终安装的仍是旧版、提示 Could not find package，或装上了但 vendor/package/ 下没看到预期的代码变更。根本原因通常是稳定性策略和分支解析逻辑不匹配。
- 默认
minimum-stability是stable，dev-master被直接过滤掉；需在composer.json顶层加：{"minimum-stability": "dev", "prefer-stable": true}或临时运行：composer require vendor/package:dev-master --stability=dev
- Composer 会尝试从
dist（zip 包）安装，但 dev 分支通常不生成 dist，得强制走source：加--prefer-source参数，确保检出真实 Git 提交 - 若包启用了
repositories自定义源，注意优先级：packagist.org 的dev-master可能覆盖你本地path或vcs源里的同名分支
用 # 后缀精确锁定某次提交（推荐做法）
比起模糊的 dev-master，用 commit hash 锁定是唯一可靠方式，尤其用于修复线上问题或验证 PR 补丁。
- 格式严格为：
"vendor/package": "dev-main#7f8c4d9a2e1b3c4d5e6f7a8b9c0d1e2f3a4b5c6d"（注意不是dev-main#7f8c4d9） - hash 必须来自目标分支（如 main）的线性历史；若该提交在 feature 分支上、尚未 merge，Composer 会找不到
- 执行后检查
composer.lock中对应项的source字段，确认reference值与你指定的一致，且type是git - 升级时 Composer 不会自动跳到新 commit——这是优点，也是缺点：你得手动改 version 字符串并重装
安装后如何验证是否真用上了目标 commit
别只信 composer show 输出的 version 字段，它常显示 dev-main，掩盖真实 commit。
- 进
vendor/vendor-name/package-name/目录，运行：git rev-parse HEAD
对比是否与你指定的 hash 一致 - 看
composer.lock里该包条目下的source.reference字段，必须是完整 40 位 hash - 如果项目用了
composer install --no-dev，而目标包被列为require-dev，它根本不会被安装——检查依赖声明位置 - 某些私有 GitLab/GitHub 仓库需要配置
auth.json才能 clone source，否则 fallback 到 dist 失败，导致安装中断
Composer 的 dev 分支安装本质是 Git 操作的封装，所有“奇怪行为”几乎都源于对 Git 分支模型、Composer 稳定性策略或锁文件机制的理解偏差。最稳妥的做法永远是：明确分支名 + 完整 commit hash + --prefer-source + 核查 composer.lock 和实际 git rev-parse 输出。
