composer如何指定包的特定分支或提交？（dev-main#commit用法）

直接写”vendor/package”: “dev-main#abc1234″即可，composer原生支持该语法，表示拉取main分支并检出指定commit；常见错误是误用@符号或遗漏dev-前缀，导致解析失败。

composer.json 里怎么写 dev-main#commit 这种语法

直接写 "vendor/package": "dev-main#abc1234" 就行，Composer 会自动识别为「main 分支 + 指定提交哈希」。它不是特殊语法，而是 Composer 对版本约束的原生支持——dev- 前缀表示开发分支，# 后面是 git commit hash 或 tag 名。

常见错误是把 # 写成 @（比如 dev-main@abc1234），这会导致 Composer 报错 Could not parse version constraint；或者漏掉 dev- 前缀，只写 main#abc1234，结果被当成无效版本号忽略。

• dev-main#abc1234：拉取 main 分支，检出到 abc1234 提交（推荐用于临时验证某次修复）
• dev-develop#v2.3.0-patch：支持分支名含斜杠或短横，只要 Git 能 checkout 就行
• commit hash 必须是目标仓库中真实存在的，否则 composer install 会卡在 Loading composer repositories 后报 Failed to download vendor/package

为什么有时候 dev-main#commit 不生效？

根本原因通常是 Composer 缓存了旧的包信息，或者本地已安装的版本锁在 composer.lock 里没更新。它不会自动重新解析分支最新状态——你改了远程 commit，但 lock 文件还记着上次的 hash 或 dist URL。

• 必须运行 composer update vendor/package（不是 install），否则不重新解析版本约束
• 如果 composer.lock 已存在且包含该包，得先删掉 vendor/vendor/package 目录再 update，否则可能复用旧的源码
• 私有 Git 仓库要注意 ssh key 权限：如果用 git@... 地址，而当前用户没配好 key，会静默 fallback 到 https 并失败，错误提示可能是 Failed to clone https://...（即使你写的是 SSH 地址）

dev-main#commit 和 path repository 的区别在哪

前者从远端 Git 拉代码，后者直接软链接本地路径。用途完全不同：dev-main#commit 是临时锁定某次提交做测试或发布前验证；path 是本地开发时绕过 Git、直接改源码并实时生效。

• 用 dev-main#commit 时，vendor/ 下是完整克隆，带 .git 目录，可 git log 查看历史
• 用 path 时，vendor/ 下是符号链接，改本地源码立刻反映，但无法保证别人环境一致
• 二者不能混用：如果 composer.json 里同时配置了 repositories type path 和 dev-main#commit，Composer 优先走 path，完全忽略 commit 指定

commit hash 写不全会怎样？

可以缩写，但必须唯一。Git 要求至少 4 位且能无歧义定位到一个 commit。Composer 底层调用 Git，所以也遵循这个规则。

• dev-main#abc：如果仓库里有多个以 abc 开头的 commit，会报 fatal: ambiguous argument 'abc'
• dev-main#abcd123：7 位通常够用，CI 环境建议写满 40 位避免意外
• 别用 github 的 short SHA（如 PR 页面显示的 7 位），要从 git log 或 API 获取真实 commit hash；GitHub ui 上点进 commit 页面，URL 末尾那段就是

实际项目里最常被忽略的是：写了 dev-main#xxx 后没 run update，或者忘了删 lock 文件里的旧记录。结果跑起来还是老代码，debug 半天发现根本没拉新提交。