Composer因默认匿名调用GitHub API触发403或限流，需配置带public_repo权限的fine-grained Token：全局执行composer config -g github-oauth.github.com ，并确认Token权限、Composer版本≥2.2.0、未混用SSH URL。
Composer 安装或更新时频繁报 403 Forbidden 或 API rate limit exceeded，不是网络问题，也不是 GitHub 账号异常——是 GitHub 已对未鉴权的 API 请求实施严格限流（匿名请求仅 60 次/小时），而 Composer 默认走的就是匿名请求。
为什么 Composer 会触发 GitHub 限流
Composer 在拉取 composer.json 中声明的 "type": "package" 或私有仓库、GitHub 上未打包成 Packagist 的分支/Tag 时，会直接调用 GitHub API 查询 commit、zipball 地址等元数据。这个过程不走 Git 协议，而是走 HTTPS + GitHub REST API，且默认无认证头。
常见触发场景包括：
- 安装依赖含
"github.com/xxx/yyy": "dev-main"这类直接引用 GitHub 分支的写法 - 使用
repositories自定义了"type": "vcs"且 URL 是https://github.com/... - 项目中依赖某个包，其
composer.json的source指向 GitHub HTTPS 地址
配置 GitHub Token 的两种可靠方式
Token 必须带 repo 权限（私有库必需）或至少 public_repo（公开库够用）。不要用 Personal Access Token 的旧版（Classic），必须用 fine-grained token 并显式勾选 Contents 权限。
生效优先级：命令行参数 > 全局配置 > 项目级配置。推荐用全局配置，一劳永逸：
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
- 生成 Token 后，执行：
composer config -g github-oauth.github.com <your_token_here></your_token_here> - 验证是否写入：
composer config -g github-oauth.github.com（应输出 token） - 注意：该配置写入的是
COMPOSER_HOME/config.json，不是项目下的composer.json
如果只希望当前项目生效（比如 CI 环境隔离），可省略 -g 参数，但需确保 composer.json 所在目录为工作目录。
Token 配置后仍 403？检查这三点
Token 本身有效 ≠ Composer 能正确使用它。以下情况会导致配置“看似成功”实则失效：
- Token 权限不足：fine-grained token 未开启
Contents（read-only 即可），或 Classic Token 未勾选repo - Composer 版本太老：
composer --version低于2.2.0可能忽略部分认证逻辑，升级到最新稳定版（composer self-update） - 用了
git@github.com:xxx/yyy.git这种 SSH URL：Composer 不会为此类 URL 发送 GitHub API 请求，也就不会用上 Token——但若composer.json里混用了 HTTPS 和 SSH 源，或 Packagist 元数据里记录的是 HTTPS，仍可能触发 API 调用
CI 环境下 Token 的安全传递
GitHub Actions、GitLab CI 等环境禁止明文写 Token 到配置文件。正确做法是通过环境变量注入：
- GitHub Actions 中，把 Token 存为 Secret（如
GITHUB_TOKEN），然后在 step 中运行：composer config -g github-oauth.github.com ${{ secrets.GITHUB_TOKEN }} - 避免用
echo '{...}' > ~/.composer/auth.json手动拼 JSON——容易格式错误或权限问题，composer config命令会自动处理转义和文件权限 - Docker 构建时，不要把 Token 写进 Dockerfile 或构建缓存；应在
docker run时用-e注入，并在容器内执行composer config -g
Token 泄露风险远高于限流问题本身。哪怕只是临时 CI job，也别图省事 echo 到文件里——Auth 文件一旦被意外上传或日志打印，就等于交出仓库读写权。
