直接写"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里同时配置了repositoriestype 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 半天发现根本没拉新提交。 
