Composer怎么解决GitHub限速问题_Composer GitHub API配额处理方案-composer-PHP中文网

composer卡在github api请求上，根本原因是未认证调用触发每小时60次配额限制；解决方法是配置github oauth token提升至5000次/小时，并禁用api fallback、切换国内镜像源。

composer怎么解决github限速问题_composer github api配额处理方案

Composer 会卡在 github.com 的 API 请求上，根本原因是它默认用未认证方式调 GitHub API，每小时只有 60 次配额 —— 一个中等规模项目 composer install 就可能超限，直接报错或无限等待。

为什么 Composer 会触发 GitHub API 限速

Composer 在解析 composer.json 依赖时，会大量调用 GitHub API 获取仓库元数据（如 tag、commit、package info），尤其是使用 "type": "package" 或私有仓库时。未登录 GitHub 账户的请求走的是匿名配额池，RateLimit-Limit: 60，RateLimit-Remaining: 0 后就卡住。

常见错误现象：Failed to download vendor/package: Could not parse version information，或长时间停在 Loading composer repositories with package information
不是网络慢，是 GitHub 直接拒绝响应 —— 查看 composer -v install 输出末尾的 HTTP 状态码，大概率是 403 或 429
即使能 clone 下来，API 阶段失败也会导致依赖解析中断，composer.lock 无法生成或更新

配置 GitHub OAuth Token 绕过匿名配额

这是最直接有效的解法：让 Composer 以你个人账户身份发请求，配额升至每小时 5000 次（且不共享）。

Github Stars Analyzer

抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...

下载

去 https://www.php.cn/link/f4380fd29ac34f2610014e8361d088fb 创建新 token，勾选 repo 权限（仅需读取权限，public_repo 对公开项目足够）
执行命令写入全局配置：composer config -g github-oauth.github.com <your_token_here></your_token_here>
验证是否生效：composer config -g --list | grep github-oauth 应显示已设置
注意：token 不要硬编码进项目 composer.json；若用 CI/CD，应通过环境变量注入，例如 GitHub Actions 中设 COMPOSER_AUTH 环境变量为 {"github-oauth": {"github.com": "${{ secrets.GITHUB_TOKEN }}"}}

切换镜像源 + 禁用 GitHub API 回退机制

国内用户光加 token 可能还不够 —— GitHub 域名本身访问不稳定，DNS 解析或 TLS 握手失败会导致 Composer 自动降级回“GitHub API fallback”，反而更易触发限速。

优先用国内镜像源替代 packagist.org：composer config -g repo.packagist composer https://packagist.phpcomposer.com（已停用）或更推荐 https://packagist.laravel-china.com（需确认当前可用性）
关键一步：禁用 Composer 的 GitHub API 自动 fallback，强制走 Git 协议下载：composer config -g github-protocols https,ssh，再加 composer config -g use-github-api false
如果项目依赖含 "dist" 指向 github.com 的 zip 包，可配合 hosts 或代理工具（如 ghproxy.com）替换域名 —— 例如把 https://api.github.com/repos/xxx/yyy/zipball/abc 改成 https://ghproxy.com/https://github.com/xxx/yyy/archive/abc.zip，但该路径需在 composer.json 中显式定义 dist.url 才生效

CI/CD 场景下避免 token 泄露和重复消耗

自动化流程里高频运行 composer install 容易集中耗尽配额，尤其多个 job 并行时。

不要在每个 job 里都跑 composer update —— composer install 复用 composer.lock 几乎不触发 API 请求
GitHub Actions 中，用 ${{ secrets.GITHUB_TOKEN }} 而非自建 token，它自带更高配额且作用域自动限制在当前 repo
缓存 vendor/ 和 ~/.composer/cache 目录，避免重复下载和解析；缓存命中后，Composer 根本不会碰 GitHub API
若必须 update，加 --no-interaction --prefer-dist 减少交互和源码拉取，降低 API 调用频次

真正麻烦的不是配额数字，而是 Composer 在失败时默认静默重试、不报明确错误，让人误以为是网络问题。一旦看到 Loading composer repositories... 卡住超过 30 秒，第一反应应该是检查 RateLimit-Remaining 响应头，而不是反复刷新 DNS 或换代理。