必须配置GitHub Personal Access Token才能解决CI中GitHub API限流问题；镜像源仅加速Packagist元数据和ZIP包下载，不代理GitHub API请求（如/repos/commits、/tags），而vcs类型、dev-*分支、私有库等仍直连api.github.com，未认证时受限于每小时60次配额。
CI里配了镜像源为什么还报GitHub API rate limit
因为镜像源（如阿里云、腾讯云）只缓存 packagist.org 的元数据，不代理 GitHub API 请求。Composer 在安装时仍会直接调用 https://api.github.com 获取 VCS 包的 tag、commit 或 zip 下载链接——尤其是遇到 "type": "vcs"、私有仓库、或 Packagist 尚未同步的新包时。
常见现象包括：
-
composer install -v日志里出现Reading composer.json of vendor/package (dev-main)后卡住，接着报403 rate limit exceeded - 本地跑得通，CI 每次构建都失败（因为 CI 是干净环境，无持久 token，每次都是全新匿名请求）
- 即使配置了
repo.packagist镜像，composer diagnose仍提示Github API is slow
GitHub Actions 中安全注入 Token 的正确写法
不能把个人 token 硬编码进 workflow YAML，也不能提交 auth.json 到仓库。必须用 secrets.GITHUB_TOKEN（Actions 自带，作用域限当前 repo）或团队级 secret。
实操建议：
- 在 workflow 中用环境变量注入：
COMPOSER_AUTH='{"github-oauth":{"github.com":"${{ secrets.GITHUB_TOKEN }}"}' - 或者运行命令配置：
composer config --global github-oauth.github.com "${{ secrets.GITHUB_TOKEN }}"（注意：域名必须是github.com，不是api.github.com） - 若项目含私有 GitHub Enterprise，则需对应配置
github-oauth.your-ghe-domain.com - 避免使用
composer config --global后再 commitauth.json—— 权限可能被覆盖，且易泄露
镜像源 + Token 双配置才是完整方案
只换镜像源解决不了 GitHub API 限流；只配 Token 在纯 Packagist 场景下又略显冗余。二者叠加才能覆盖全部路径。
推荐组合：
- 全局设置国内镜像：
composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/ - 同时配 Token：
composer config --global github-oauth.github.com "${GITHUB_TOKEN}" - CI 中优先用
secrets.GITHUB_TOKEN，它默认有public_repo权限，够绝大多数开源依赖使用 - 若依赖私有库，且
secrets.GITHUB_TOKEN权限不足，才启用带repo权限的 personal access token，并设为 secret
验证 Token 是否真正生效的两个关键点
配完不验证，等于没配。最容易忽略的是匹配逻辑和权限范围。
检查方式：
- 运行
composer config -g github-oauth.github.com—— 应输出 token 前几位（Composer 自动掩码），不是空值或报错 - 执行
composer install -v 2>&1 | grep "Using GitHub token"—— 日志中必须出现该字样，否则说明请求未走认证路径 - 手动测试 API 限速状态：
curl -H "Authorization: token ${GITHUB_TOKEN}" https://api.github.com/rate_limit，确认返回中rate.limit是5000而非60 - 注意：Token 对 host 严格匹配，
github.com和www.github.com视为不同域名，后者不会命中
