“could not read from remote repository”是git权限或配置问题，非composer缺陷；需验证ssh密钥、检查url格式、设置git用户信息、确认ssh-agent继承，或改用https协议/--prefer-dist绕过。
Composer install 报 “Could not read from remote repository” 怎么办
这不是 Composer 的 bug，而是它调用系统 git 命令失败的明确信号。只要 composer.json 里定义了 repositories（尤其是私有 Git 仓库），或依赖包指定了 "dev-*" 分支、用了 --prefer-source，Composer 就必须走 git clone——此时任何 Git 层面的权限/配置问题都会直接暴露出来。
- 先手动验证：在项目根目录运行
git clone git@github.com:your-org/private-package.git test-clone，看是否失败。如果失败，Composer 必然失败 - 检查远程地址协议：SSH 地址（
git@github.com:...）要求本地配好密钥；HTTPS 地址（https://github.com/...）可能卡在凭据管理器或网络代理 - 别信 IDE 内置终端：新开一个干净终端执行
git --version和ssh -T git@github.com，避免环境变量污染干扰判断
为什么 ssh -T git@github.com 成功，但 Composer 还是 clone 失败
因为 Composer 不一定用你当前 shell 的 SSH 配置。它可能被以下因素绕过：
-
composer.json中repositories的url写成ssh://git@github.com/...而不是git@github.com:...，某些版本 Git 对 URL 格式更敏感 - Git 全局没设
user.name和user.email：部分企业 Git 服务器或容器环境会拒绝无用户信息的克隆请求，哪怕只是读操作 - SSH Agent 没被 Composer 继承：某些 CI 环境或 Docker 容器里，
ssh-agent启动后未导出SSH_AUTH_SOCK，导致 Composer 子进程看不到密钥 - 私有仓库用了非标准端口（如
git@gitlab.example.com:2222:user/repo.git），但~/.ssh/config里没对应 Host 配置
快速绕过 Git 权限问题的实操手段
不是所有场景都必须修通 SSH；临时让 Composer 走 HTTPS 是最稳的逃生通道：
- 全局强制 GitHub 走 HTTPS：
composer config -g github-protocols https - 单项目覆盖：
git config url."https://github.com/".insteadOf "ssh://git@github.com/"（注意协议前缀要匹配） - 跳过源码克隆，改用压缩包：
composer install --prefer-dist，只要包在 Packagist 或镜像站有 dist 包就能绕开 Git - 清除缓存再试：
composer clear-cache，避免旧的失败状态残留影响新尝试
Git 本身报 “Permission denied (publickey)” 的硬核修复点
当 ssh -T git@github.com 都失败时，问题不在 Composer，而在 SSH 链路本身。关键检查项：
-
ls -l ~/.ssh/id_*确认私钥权限是600（chmod 600 ~/.ssh/id_rsa），否则 OpenSSH 直接拒载 -
eval "$(ssh-agent -s)"后必须跟ssh-add ~/.ssh/id_ed25519，不能只启动 agent - Windows 用户：Git Bash、VS Code 终端、PowerShell 的
ssh-agent是各自独立的，别在一个终端配好就以为全系统生效 - 公司网络屏蔽 22 端口？改用 HTTPS 协议是最实际的选择，而不是折腾 SSH over HTTPS
真正卡住人的，往往不是“会不会配”，而是“配给谁用”——Composer 启动的子进程是否继承了你的 SSH Agent 环境变量，以及 Git 是否在那个上下文里能读到正确的密钥路径。别急着重装 Git 或 chmod 777，先用 git clone 手动复现，再一层层剥开。
