composer 支持通过 dev-branch#commit-hash 格式安装指定 git 提交，需确保哈希存在于远程分支、版本约束格式正确，并可能需 --stability=dev；create-project 不支持该语法，应改用 git clone + composer install。
用 composer require 安装指定 Git 提交哈希的包
Composer 本身不支持直接按 commit hash 安装，但可以通过在版本约束中写死 dev-branch-name#commit-hash 实现。关键是：必须确保该 hash 在远程仓库可访问，且对应分支（或默认分支）存在该提交。
常见错误现象：Could not find package vendor/name at version dev-main#abc1234 —— 多半是 hash 写错、分支名不对，或远程仓库未 fetch 到最新提交。
- 确认目标提交存在于远程（比如 GitHub 上能打开
https://github.com/vendor/name/commit/abc1234） - 用
git ls-remote https://github.com/vendor/name.git abc1234验证 hash 是否真实存在 - 版本字符串格式必须为
dev-main#abc1234（main换成实际分支名），不能写成abc1234或#abc1234 - 如果包没声明
"minimum-stability": "dev"，需临时加--stability=dev参数
composer.json 中手动写死 commit hash 版本
适合团队协作或 CI 场景，避免本地 require 命令被覆盖。本质和命令行一样，只是把版本约束写进配置文件。
使用场景：锁定某次紧急修复的提交，又不想发新 tag；或测试尚未合并到稳定分支的 PR 分支提交。
- 在
composer.json的require字段里写："vendor/name": "dev-develop#def5678" - 运行
composer update vendor/name（不要用install，它只读 lock 文件） - 注意
composer.lock里会记录完整 commit hash 和 source URL，下次install才会复现 - 如果之后该分支被 force push，hash 仍有效，但内容可能已变 —— 这是 Git 本身的语义，不是 Composer 的 bug
为什么不能用 composer create-project 直接指定 hash
create-project 只接受 package:version 形式，而 version 必须是合法的 Composer 版本约束（如 1.2.3、dev-main），不解析 # 后缀。强行写会报 Invalid version string。
替代做法：先 git clone 到本地目录，再进目录运行 composer install。
- 执行
git clone --depth=1 -b main https://github.com/vendor/name.git && cd name && git reset --hard abc1234 - 确认
composer.json存在且无语法错误 - 运行
composer install --no-dev（按需） - 这种方式绕过 Packagist 解析，完全由 Git 控制源码状态
容易被忽略的兼容性细节
Git commit hash 安装依赖于 Composer 的 VCS repository 机制，默认启用，但某些私有仓库或代理环境可能禁用或缓存旧 refs。
- 如果始终拉不到指定 hash，先清空 Composer 的 cache：
composer clear-cache - 检查是否启用了
composer config -g repos.packagist.org false类似配置，这会关闭 Packagist 自动发现 - 私有 GitLab/GitHub Enterprise 用户要注意：URL 必须带协议（
https://或git@），且域名需在composer.json的repositories中显式声明 - PHP 8.2+ 下某些旧版 Composer（composer self-update 升级到 2.x
真正麻烦的不是写法，而是 hash 对应的代码是否包含完整依赖树 —— 比如它引用了另一个未发版的子包，那还得同步锁那个子包的 hash。
