Composer通过GitHub API获取包信息时易因匿名请求触发速率限制，配置个人访问令牌可提升限额至每小时5000次，结合缓存机制与镜像源可进一步降低API调用频率。
Composer 在安装或更新依赖时，如果目标包托管在 GitHub 上，会通过 GitHub API 获取仓库信息。当请求过于频繁，GitHub 会触发 API 速率限制（Rate Limit），导致 Composer 报错，例如 "API limit exceeded" 或 "Could not fetch https://api.github.com/..."。以下是 Composer 如何处理该问题以及应对方法。
Composer 如何与 GitHub API 交互
Composer 使用 GitHub API 来：
- 获取公开仓库的元信息（如 tags、branches）
- 验证包是否存在
- 下载压缩包（zipball）
未认证的请求基于 IP 限制，每小时最多 60 次。认证后可提升至每小时 5000 次。Composer 默认以匿名方式访问，因此容易触发限流。
使用个人访问令牌（Personal Access Token）绕过限制
最有效的解决方式是配置 GitHub Token，使 Composer 请求带上身份认证：
- 前往 GitHub Tokens 页面 创建一个具有
repo和read:packages权限的 Token - 在本地运行命令保存 Token：
composer config --global github-oauth.github.com
此后 Composer 所有 GitHub 请求都会使用该 Token 认证，大幅提升请求限额。
缓存机制减少重复请求
Composer 自动缓存已获取的包信息和 dist 文件：
- 元数据缓存：避免重复调用 API 查询版本列表
- Zip 包缓存：下载后的压缩包会存储在本地（
~/.cache/composer/files）
确保系统有足够磁盘空间，并避免频繁清空缓存（如不用 composer clear-cache 过度）。
使用镜像或私有包管理器（高级方案）
在团队或 CI 环境中，可考虑：
这些方式能显著降低 GitHub API 调用次数。
基本上就这些。只要配置好 GitHub Token，大多数 Rate Limit 问题都能解决。缓存和镜像则是优化大规模使用的补充手段。
