可以，但需用dev-前缀加分支名再接#commit-hash（如dev-main#abc1234），且必须在repositories中声明vcs源；裸哈希不被识别，否则报“could not find a matching version”。
Composer 能不能直接用 commit hash 安装包？
可以，但不是“指定提交号”这么简单——composer require 或 composer update 不接受裸的 commit hash 作为版本号，必须配合 dev- 前缀 + 分支名（或 dev-main、dev-master）才能让 Composer 识别为“开发分支的某次提交”。否则会报错：Could not find a matching version of package xxx。
如何在 composer.json 中锁定到某个 commit？
使用 "branch-name#commit-hash" 语法，写在 require 字段里。注意：这仅在该包使用 Git 仓库（type: vcs）且 Composer 能访问该仓库时才生效。
例如，要安装 monolog/monolog 的 main 分支上某次提交：
"require": {
"monolog/monolog": "dev-main#abc1234"
}
其中 abc1234 是短 commit hash（完整 hash 也可，但短 hash 更常用）；dev-main 表示“把 main 分支当作一个开发版本”，#abc1234 是 Composer 的“提交锚点”语法。
- 必须确保该仓库已声明为 VCS 类型（如 GitHub、GitLab），或已在
repositories中显式配置了{"type": "vcs", "url": "https://github.com/Seldaek/monolog"} - 如果包已发布稳定版本（如
3.0.0），而你又写了dev-main#...，Composer 默认不会自动降级；需先composer remove monolog/monolog再require - 执行后，
composer.lock里会记录实际解析出的完整 commit hash 和 source URL，下次install就能精确复现
为什么 dev-main#xxx 有时不生效？
常见原因不是语法错，而是底层机制没被触发：
- 包源未启用 VCS 模式：默认 Packagist 上的包走 dist（zip 包），不支持 commit 锚点；必须在
repositories中覆盖该包，强制走 Git 源 - commit hash 对应的提交不在目标分支的可访问历史中（比如该提交只存在于本地分支、或已被 force-push 删除）
- 用了
minimum-stability: stable且没配prefer-stable: true，Composer 可能忽略dev-前缀的版本（即使你写了dev-main#...） - hash 写错位数或大小写（Git hash 不区分大小写，但某些 Git 服务校验严格）
有没有比 commit hash 更可靠的替代方案？
有，但适用场景不同：
-
dev-main（无 hash）：拉最新 dev 分支，适合持续集成调试，但不可重现 - 带 tag 的版本如
v3.0.0@dev：等价于dev-main但语义更清，仍不锁定具体提交 - fork 后打私有 tag：在自己 fork 的仓库里基于目标 commit 打个
my-fix-20240501，然后 require"yourname/monolog": "my-fix-20240501"——这是最稳定、最易协作的方式
commit hash 锁定本质是“临时兜底手段”，一旦项目进入协作或长期维护阶段，就该转为 fork + tag 方案；否则下个月 CI 就可能因为上游分支重写而失败。
