“Could not read from remote repository”错误本质是Git认证失败，而非Composer本身问题，系其调用git clone时被GitHub/GitLab/Gitee等远程服务拒绝，常见于私有包或自定义VCS仓库；需据SSH或HTTPS协议分别排查密钥配置、PAT令牌、凭证缓存及Git全局设置。
“Could not read from remote repository” 错误本质是 Git 认证失败
这个报错不是 Composer 本身的问题，而是它调用 git clone 时被远程 Git 服务（GitHub/GitLab/Gitee）拒绝了。常见于私有包、自定义 repositories 或使用 SSH/HTTPS 协议拉取的 VCS 包。关键线索在报错末尾：比如 git@github.com: Permission denied (publickey) 或 remote: Invalid username or password。
- 先确认你是否在
composer.json里写了"type": "vcs"的仓库，且url指向私有 Git 地址 - 如果是 HTTPS 地址（如
https://github.com/user/repo.git），Composer 默认走 Git 的凭证系统，不读auth.json——除非你显式配置了github-oauth - 如果是 SSH 地址（如
git@github.com:user/repo.git），认证完全由本地ssh-agent和密钥文件控制，和 Composer 配置无关
重置 GitHub 私有库鉴权：优先用 PAT 替代密码
GitHub 已停用密码登录 Git，必须用 Personal Access Token（PAT）。用错方式会导致反复失败。
- 去 GitHub Settings → Developer settings → Tokens (classic) 创建新 token，勾选
repo权限（read:packages不够） - 执行：
composer config --global github-oauth.github.com <your-token-here>—— 注意域名必须是github.com，不能带www.或路径 - 删掉旧的凭据缓存：
git credential reject <<EOF protocol=https host=github.com EOF
- 再试
composer install；若仍失败，加-v看具体卡在哪一步
SSH 方式失效？检查密钥加载和代理配置
SSH 报错常被误判为网络问题，实际多是密钥没加载或 ssh-agent 没启动。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
ssh -T git@github.com，看到Hi xxx! You've successfully authenticated...才算通 - 如果提示
Could not open a connection to your authentication agent，先执行：eval $(ssh-agent)，再ssh-add ~/.ssh/id_rsa（或你的私钥路径） - 公司环境可能用了中间人代理，SSH 会静默失败；可临时测试：
ssh -o ProxyCommand="none" -T git@github.com -
composer.json中的url必须严格匹配 SSH 格式：git@github.com:user/repo.git，不能写成https://或漏掉.git后缀
别忽略缓存和全局污染
很多“重置后还是不行”其实是缓存或权限残留导致的假象。
- 清除 Composer 缓存：
composer clear-cache（不是composer dump-autoload） - 检查 Git 全局配置是否缺失：
git config --global user.name和git config --global user.email必须已设置 - 确认当前用户对项目目录有完整所有权：
ls -ld . composer.json vendor/，若vendor/属主是root，直接rm -rf vendor/再重装，比chown更可靠 - 避免混用
sudo composer install和普通用户命令——一次sudo就可能污染整个vendor/目录结构
最易被忽略的是：GitHub 的 PAT 权限变更不会自动同步到已缓存的 Git 凭据中，必须手动 git credential reject 清除；而 SSH 连接失败时，ssh -vT 输出里的 debug1: key_load_public 行才是判断密钥是否被识别的关键证据。
