“Branch does not exist”是因composer.json中指定的分支名（如dev-xxx）在远程仓库真实不存在，需用git ls-remote验证；常见错误包括拼写错误、大小写不符、前缀混用或分支已被删除。
Composer install 时提示 “Branch does not exist” 是什么情况
这通常不是网络或权限问题，而是 composer.json 里写了根本不存在的分支名，比如拼错、远程仓库已删分支、或用了未推送的本地分支。Composer 在解析 "dev-xxx" 或 "dev/xxx" 时会严格校验远程是否存在该引用，校验失败就直接中止。
怎么快速确认分支在远程是否存在
别靠猜，用 Git 命令直连源仓库验证：
- 先看包的源地址：
composer show vendor/package输出里的source字段（通常是 Git URL） - 然后执行：
git ls-remote --heads <i>git_url</i> | grep xxx，例如git ls-remote --heads https://github.com/myorg/mylib.git | grep dev-fix-login - 如果没输出，说明分支确实不存在；有输出但格式是
abc123 refs/heads/dev-fix-login，才表示有效
注意：GitHub/GitLab 页面上看到的“Branches”列表可能缓存，ls-remote 才是真实权威来源。
composer.json 中分支写法的常见错误与修复
分支名必须和远程 refs/heads/ 下的名称完全一致，大小写、斜杠、前缀都不能错：
-
"dev-master"是历史遗留写法，现代 Composer 默认不推荐；若远程已删master改用main，就得同步改成"dev-main" -
"dev/feature/login"这种带斜杠的写法，要求远程分支名就是feature/login（不是feature-login或dev-feature/login） - 别混用前缀：
"dev-dev/xxx"或"dev-xxx"对应远程xxx分支，但"dev-xxx"和"dev/xxx"是两个不同分支，不能互换 - 如果想强制走某次提交，改用 commit hash 更稳：
"dev-main#abc123"，只要该 commit 存在且可访问即可
CI/CD 或多人协作中分支突然失效怎么办
最常发生在 PR 合并后分支被自动删除，或维护者手动清理了旧开发分支。此时依赖它的 composer.json 就会集体报错：
- 立刻检查 CI 日志里失败的具体包名和分支字段，定位到哪一行
"version"或"dev-xxx" - 不要临时切到
main或stable版本硬顶——可能引入兼容性断裂；优先联系包维护者确认替代分支或发布新 tag - 若只是临时调试需要，可用
composer require vendor/package:dev-main --no-update覆盖，再composer update vendor/package拉取 - 长期方案：项目中尽量避免锁定开发分支，改用语义化版本（如
^2.1）或带哈希的dev-main#xxx，降低对分支生命周期的依赖
分支名不是路径也不是标签，它是个 Git 引用指针，一旦断开，Composer 就没法凭空恢复——得靠人去核对、修正、同步。
