可通过 branch#commit-hash 语法在 composer.json 中依赖指定 Git 提交，如 "monolog/monolog": "dev-master#abc1234"，Composer 会克隆仓库并检出对应 commit，确保代码状态精确，适用于临时修复或未发布功能，但应避免长期使用以保障项目可维护性。
当你在使用 Composer 管理 PHP 项目依赖时，有时会遇到需要依赖某个包的特定 Git commit hash 的情况，比如该功能尚未发布版本，或者你需要临时应用一个未合并的修复。Composer 支持直接通过 Git commit 来指定依赖版本。
如何在 composer.json 中依赖某个 Git commit
你可以在 composer.json 文件的 require 字段中，将包的版本设置为具体的 Git commit hash（完整的或简短的都可以），前提是这个包的源是通过 VCS（如 GitHub、GitLab）方式可访问的。
示例：{
"require": {
"monolog/monolog": "dev-master#abc1234"
}
}
这里的 #abc1234 表示你要安装 monolog/monolog 的 dev-master 分支，并锁定到提交哈希为 abc1234 的那个版本。
你也可以不写分支名，只写 commit hash，但建议带上分支名以确保上下文清晰：
"monolog/monolog": "dev-main#xyz5678"
Composer 是如何处理 commit hash 依赖的？
当 Composer 解析到带有 commit hash 的包时，它会：
- 从配置的 VCS 源（如 GitHub）克隆仓库（或使用缓存）
- 检出指定的分支（如 dev-master）
- 然后执行 git checkout 到指定的 commit hash
- 安装该快照状态下的代码
这意味着你获取的是某一个确切的代码状态，不会自动更新，非常适合临时调试或等待 PR 合并。
注意事项与最佳实践
使用 commit hash 虽然灵活，但也带来一些维护上的问题，需要注意：
- 不可变性：commit hash 是固定的，但前提是该 commit 一直存在于远程仓库。如果仓库被重置或强制推送，可能失效。
- 不利于长期维护：建议仅用于临时方案，尽快替换为正式版本或分支别名。
- 安全性：确保你知道这个 commit 做了什么，避免引入未知风险。
- 锁文件记录：composer.lock 会记录实际安装的版本和来源，便于团队共享一致环境。
如果你频繁依赖私有仓库或特殊分支，考虑在 repositories 字段中显式定义 VCS 源：
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/your-company/your-private-package"
}
],
"require": {
"your-company/your-private-package": "dev-develop#abcd1234"
}
}
总结
Composer 允许你通过 branch#commit-hash 的语法精确控制依赖的代码版本。这在调试、验证补丁或等待发布时非常有用。只要包支持 VCS 安装，Composer 就能拉取对应 commit 的代码。但要注意避免在生产环境中长期依赖未发布的 commit，保持项目的可维护性和可升级性。
基本上就这些。用得好，它是救急利器；用多了，可能是架构或协作流程需要调整的信号。
