“Could not fetch origin”或“fatal: couldn’t find remote ref”错误主因是远程分支变更/删除、Git凭据失效、SSH代理未加载或分支名大小写不一致；需检查composer.lock中reference有效性、远程分支真实存在性、凭据缓存及SSH环境，并统一分支命名规范。
Composer install报错“Could not fetch origin”或“fatal: couldn’t find remote ref”
这类错误不是 Composer 本身故障，而是它调用 git 命令拉取源码时，远程仓库的分支名已变更、被删除，或本地 Git 凭据缓存了过期/无效的访问权限。常见于私有 GitLab/GitHub 仓库、自建 Gitee 或企业内网 Git 服务。
典型现象：composer install 卡在 “Cloning into ‘…’” 后报错，或直接输出 fatal: couldn’t find remote ref dev-feature-x；git clone https://xxx/repo.git 单独执行却能成功——说明问题不在网络，而在 Composer 调用时的上下文凭据或引用解析逻辑。
- 检查 composer.lock 中记录的 source 引用：打开
composer.lock，搜索"source"字段，确认"reference"对应的 commit hash 是否真实存在于目标仓库（尤其注意是否是已 force-push 覆盖的旧提交） - 确认分支是否存在：运行
git ls-remote --heads https://your-git-server.com/user/repo.git（把 URL 替成实际地址），看输出里有没有你锁文件里写的分支名 - 别依赖 IDE 内置终端：Git 凭据管理器（如 Windows Credential Manager、macOS Keychain、Linux libsecret）通常只对交互式 shell 生效；PHP 子进程调用
git时可能拿不到凭据——新开终端手动执行git -c credential.helper= store并输一次账号密码，可强制写入凭据缓存
Git 凭据失效导致 Composer 认证失败
报错含 Authentication failed、401 Unauthorized 或 Permission denied (publickey)，但你知道密码/密钥没错——大概率是 Git 凭据缓存过期或冲突。Composer 不会自己管理凭据，全靠系统 Git 的 credential helper。
- Windows：打开 “Windows 凭据管理器” → 找到 “Generic Credentials” 下以
git:开头的条目 → 删除对应 Git 服务器的凭据，再跑一次composer install，它会弹窗要求重新输入 - macOS：打开 “钥匙串访问” → 搜索仓库域名（如
github.com）→ 删除所有类型为 “Internet Password” 的相关条目 → 终端执行git config --global credential.helper osxkeychain确保启用 - Linux：若用
libsecret，运行git credential reject < /dev/null清空；若用cache，执行git config --global --unset credential.helper后改用store（凭据明文存 ~/.git-credentials） - 临时绕过凭据验证（仅调试）：
GIT_TERMINAL_PROMPT=0 GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no" composer install
SSH 密钥未加载或代理转发失败
用 SSH URL（git@xxx:repo.git）时，报 Permission denied (publickey)，但 ssh -T git@xxx 成功——说明密钥本身没问题，问题出在 PHP 进程无法访问 ssh-agent。
- 确认 agent 正在运行：
echo $SSH_AUTH_SOCK应有输出；若为空，先执行eval $(ssh-agent)，再ssh-add ~/.ssh/id_rsa - Docker / CI 环境：agent 不跨容器生效，必须在构建阶段显式加载密钥：
RUN mkdir -p ~/.ssh && echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa - Web 服务（如 Apache/Nginx）下运行 Composer：PHP 子进程默认不继承用户环境变量，
SSH_AUTH_SOCK不可用；此时必须用https+ 凭据方式，或改用 deploy token（GitLab）/personal access token（GitHub）替代 SSH
分支名大小写或拼写不一致引发的引用失败
Git 分支名区分大小写，但某些文件系统（如 Windows NTFS、macOS 默认 HFS+）不敏感。Composer 锁文件里记录的是 dev-Main，而远程仓库实际只有 dev-main，就会报 couldn’t find remote ref。
最容易被忽略的一点：Git 本身允许创建大小写不同的分支（git checkout -b Dev-Main 和 git checkout -b dev-main 可共存），但大多数 Git 服务（GitHub/GitLab）在 Web UI 创建分支时自动转为小写，而本地开发误用大写提交到 lock 文件，后续部署就失败。
- 检查远程分支真实命名：
git ls-remote --heads origin | grep -i main（加-i忽略大小写筛选） - 修正 composer.json：
"package/name": "dev-main"（统一小写），然后删掉composer.lock和vendor/，重跑composer install - CI/CD 流水线中加校验步骤：
git ls-remote --heads origin $(echo "$BRANCH_NAME" | tr '[:upper:]' '[:lower:]')，确保分支存在再触发构建
