正确写法是vendor/package:dev-branch#branch，需配置minimum-stability: dev或prefer-stable: false；含斜杠分支要URL编码；缓存导致非最新commit，应加--no-cache或用composer update；私有仓库须加vcs类型repositories。
composer require 时指定 Git 分支的正确写法
直接写 composer require vendor/package:dev-feature-branch 是错的——Composer 默认不认这种写法，会报 Could not find package 或解析成错误的版本约束。
必须用 dev- 前缀 + #分支名 后缀组合，且要确保包的 composer.json 中已声明该分支为可安装的开发版本（即 "minimum-stability": "dev" 或显式配置 "prefer-stable": false）。
-
composer require vendor/package:dev-main#main：装 main 分支（注意前后两个main含义不同：前者是 Composer 的版本别名，后者是 Git 分支名） -
composer require vendor/package:dev-develop#develop：装 develop 分支 - 如果分支名含斜杠（如
feature/login），必须 URL 编码为feature%2Flogin，否则 Composer 解析失败
为什么 require dev-* 却拉不到最新 commit？
因为 dev- 版本默认走 Composer 的缓存机制，它不会每次都去 Git 拉 HEAD；哪怕你本地删了 vendor 目录重装，也可能复用旧的 dist 包或已缓存的 commit hash。
强制刷新的方法只有两个：
- 加
--no-cache参数：composer require vendor/package:dev-main#main --no-cache - 先清空 Git 包缓存：
composer clear-cache，再执行 require
更稳妥的做法是：在 composer.json 里直接写 "vendor/package": "dev-main#main"，然后运行 composer update vendor/package ——update 默认绕过部分缓存，比 require 更可控。
私有仓库或非 Packagist 托管的 Git 项目怎么处理？
Composer 默认只从 Packagist 查包，如果你的代码在 GitHub 私仓、GitLab 内网库、甚至本地路径，必须手动加 repositories 配置。
比如 GitHub 私有项目：
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/your-org/your-private-repo"
}
]
}
关键点：
-
type必须是vcs（不是package或path），否则不支持分支解析 -
url要能被 Composer 的 Git driver 访问（HTTPS 地址需配 token，SSH 地址需本地有对应 key） - 如果用 SSH 地址（如
git@github.com:org/repo.git），composer install时可能卡住等 SSH 密码——建议提前跑ssh -T git@github.com测试连通性
分支名和 tag 名冲突时 Composer 怎么选？
如果一个 Git 仓库既有 main 分支，又有 main tag，Composer 优先匹配 tag —— 因为 tag 被视为稳定版本，而 dev-main 这种写法实际指向的是分支的“开发版本别名”，不是分支本身。
验证方式：装完后看 vendor/vendor/package/composer.json 里的 version 字段，如果是 dev-main，说明走的是分支；如果是 main（无 dev- 前缀），大概率是误匹配了 tag。
- 最保险的写法是用完整 commit hash：
composer require vendor/package:dev-main#abc1234 - 或者改用
path类型仓库 +symlink，绕过版本解析逻辑（适合本地调试）
分支名不是版本号，它只是个指针；Composer 对它的解析依赖远程仓库的元数据响应，网络抖动、GitHub API 限流、甚至分支被 force push 都可能导致安装结果和预期不一致。
