可在 composer.json 的 require 中写 “vendor/package”: “dev-branch#abc123” 指定 git commit 安装，需确保仓库为 vcs 类型、commit 存在且已推送；执行 composer update vendor/package 生效，不可用 composer require 直接输入 hash。
怎么在 composer.json 里指定某个 Git 提交（commit）安装
Composer 支持直接按 Git commit hash 安装包，但必须满足：目标仓库是 VCS 类型（如 github/gitlab），且该 commit 在默认分支或已公开的分支/Tag 上可访问。
常见错误现象：Could not find package xxx at version abc123 或 Failed to download xxx: No valid composer.json found——多数是因为 commit 不存在、未推送、或仓库未配置为 VCS 源。
- 在
composer.json的require中写成："vendor/package": "dev-main#abc123"（假设main是主分支名，abc123是完整或缩略 commit hash） - 如果目标 commit 在非默认分支（比如
feature/login），用"dev-feature/login#abc123" - 不要写成
"dev-main#abc123@dev"或加dev-前缀到 hash 后——Composer 不认这种写法 - 执行
composer update vendor/package，而不是全量update，避免意外升级其他依赖
为什么 composer require 命令不支持直接输 commit hash
composer require 设计上只接受稳定版本约束（如 ^2.0、v1.5.0、dev-main），它不解析 # 后的 commit 部分。强行写 composer require vendor/package:dev-main#abc123 会报错 Invalid version String。
- 正确做法：先手动编辑
composer.json写好dev-branch#hash格式，再运行composer update vendor/package - 如果想快速试一个 commit，可临时改
composer.json→composer install→ 验证完再切回稳定版本 - 注意：使用 commit 安装时，
composer.lock里记录的是完整 commit hash 和 source URL，不是分支名——这能保证可重现，但也意味着换网络环境时需确保该 Git 仓库仍可访问
安装后怎么确认实际拉的是哪个 commit
别只信 composer show 输出的版本号，它可能显示 dev-main，掩盖了真实 commit。
- 看
vendor/vendor/package/.git/HEAD或直接进目录运行git rev-parse HEAD - 检查
composer.lock中对应包的source字段："type": "git"+"reference": "abc123..." - 如果
source.reference是分支名（如main）而非 hash，说明你没生效 commit 锁定——大概率是composer.json写错了格式，或执行的是composer install而非update
用 commit 版本要注意的兼容性和维护风险
Commit 安装本质是绕过语义化版本约束，等于手动锁定快照。它适合临时修复、验证 PR、或等上游发版前抢跑，但不适合长期依赖。
- 该 commit 若被 force-push 覆盖，下次
composer install可能失败（Git 报reference is not a tree） - PHP 版本、扩展依赖等仍由包内
composer.json的require字段决定，不会因 commit 改变——别以为切个 commit 就能躲开 PHP 8.2 兼容问题 - 如果你 fork 了原包并改了某 commit，记得在
repositories里显式加type: vcs和你的 fork 地址，否则 Composer 还是去找原仓库
commit hash 看似精确，但 Git 仓库的可达性、分支生命周期、以及团队协作时的沟通成本，比版本号更难对齐。真要用，就把它当成“临时绷带”，不是新架构。