Composer 支持通过 dev-branch#commit_hash 语法安装指定 commit，但要求该 commit 必须存在于远程某分支且未被 force-push 删除；手动编辑 composer.json 时需严格遵循 "dev-branch#hash" 格式，并运行 composer update 生效。
用 composer require 安装指定 commit（哈希）
Composer 本身不支持直接写 commit_hash 当版本号，但可以通过 dev-branch-name#commit_hash 的语法绕过。关键是：必须确保该 commit 在远程仓库的某个分支（哪怕是 main 或 master）上存在，且未被 force-push 覆盖。
实操建议：
- 先确认目标 commit 是否可访问：在 GitHub/GitLab 页面打开对应仓库，粘贴哈希看能否定位到提交页；如果 404，说明已被删或不在公开分支上
- 运行命令如：
composer require monolog/monolog:dev-main#abc1234，其中main是分支名，abc1234是短哈希（完整哈希也行） - 不要写成
dev-main#v2.10.0这类标签名混用——#后只认 commit 哈希，不认 tag 名或语义化版本 - 执行后检查
composer.lock中该包的source字段，确认reference值是否为你指定的哈希
composer.json 里手动写 commit 版本的写法
直接编辑 composer.json 比命令行更可控，尤其适合 CI 或团队协作场景。但格式稍敏感，错一个字符就报错。
常见错误现象：
-
"monolog/monolog": "dev-main#abc1234"→ 表面正常，但若main分支最新提交不是这个哈希，Composer 可能回退到最近兼容的稳定版 - 漏掉
dev-前缀，比如写成"monolog/monolog": "main#abc1234"→ Composer 报错Could not find package ... matching your minimum-stability - 哈希写错位数或含非法字符（如空格、换行）→ 解析失败，提示
JSON decode error
正确写法示例：
"require": {
"monolog/monolog": "dev-main#abc1234567890abcdef1234567890abcdef123456"
}
之后必须运行 composer update monolog/monolog（而非 install），否则不会拉取新 commit。
为什么不能用 composer install 直接锁定 commit？
composer install 只按 composer.lock 里的 source.reference 拉代码，但它不校验该 commit 是否仍存在于远程分支。也就是说：如果你之前锁的是一个已从远程删除的 commit，install 会失败，报错类似 Failed to download monolog/monolog from source: Failed to execute git checkout...。
所以关键点是：
- commit 必须长期保留在某分支上（哪怕只是临时打个
tmp/fix-xxx分支） - CI 环境要确保 Git 配置允许 shallow clone —— 否则可能拉不到指定 commit（尤其是私有 GitLab 实例默认禁用）
- 别依赖
composer.lock里“看起来像 commit”的字符串：有些 lock 文件里reference是 tag 对应的哈希，但实际来源是 tag，不是你手动指定的 commit
替代方案：用 path 仓库临时覆盖
当 commit 已不可达，或你需要改几行代码快速验证，path 方式比死磕哈希更可靠。
做法很简单：
- 把目标仓库
git clone到本地某路径，比如~/projects/monolog-fix - 在项目根目录的
composer.json加仓库配置：
"repositories": [
{
"type": "path",
"url": "../monolog-fix"
}
],
"require": {
"monolog/monolog": "*"
}
然后运行 composer update monolog/monolog。Composer 会直接 symlink 或 copy 本地目录内容，完全绕过远程哈希有效性校验。
注意：这种写法不能进生产 composer.lock（CI 会找不到路径），仅限开发调试；上线前务必切回正式版本或可追溯的 commit 引用。
最麻烦的地方往往不是语法，而是那个 commit 到底还在不在——Git 的分布式特性让“存在”这件事本身就有条件。
