Composer卡在GitHub API请求上，根本原因是未认证调用触发每小时60次配额限制；解决方法是配置GitHub OAuth Token提升至5000次/小时，并禁用API fallback、切换国内镜像源。
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 次（且不共享）。
- 去 https://www.php.cn/link/f4380fd29ac34f2610014e8361d088fb 创建新 token，勾选
repo权限（仅需读取权限，public_repo对公开项目足够） - 执行命令写入全局配置：
composer config -g github-oauth.github.com <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 或换代理。
