Composer报403“rate limit exceeded”是GitHub对未认证API请求的限流（每小时60次），解决方法是配置GitHub OAuth Token：执行composer config --global github-oauth.github.com 并确保auth.json权限为600。
Composer 报 403 “rate limit exceeded” 不是网络问题，也不是你配错了源，而是 GitHub 拒绝了未认证的 API 请求——每小时最多只让发 60 次，用完就锁死，直到整点重置。
为什么 composer install 突然卡在 “Resolving packages” 并报 403
Composer 在解析 dev-master、dev-* 分支、私有仓库 tag 列表，或依赖里含 fork 后没改 "source" 的包时，会密集调用 https://api.github.com/。这些请求默认不带认证头，GitHub 就当你是“匿名游客”，按 IP 限流：每小时最多 60 次。
- 哪怕你只装一个包，只要它依赖 5 个 GitHub 上的 dev 分支，就可能直接耗尽额度
- 公司/学校共享出口 IP？那 60 次是大家共用的，更容易撞墙
- 错误常出现在 CI 环境反复重试、
composer create-project或composer update拉取大量开发版依赖时 - 注意：
dist包（zip 下载）走的是 Packagist CDN，不受此限；出问题的永远是source模式下的元数据查询
怎么配 github-oauth.github.com 让 Composer 走认证通道
配一个 GitHub Personal Access Token，就能把限额从 60 升到 5000 次/小时。关键是两步都得做对，缺一不可：
从 Git 仓库历史中彻底删除文件
下载
|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
- 去
https://github.com/settings/tokens/new新建 token，勾选public_repo（公开项目够用，不用给 admin:org 或 delete_repo） - 执行
composer config --global github-oauth.github.com <your_token_here></your_token_here>，token 会写进~/.composer/auth.json - 立刻检查权限：
chmod 600 ~/.composer/auth.json—— 权限不是 600，Composer 会静默忽略该文件，退回到未认证状态 - 验证是否生效：
composer diagnose输出里看到GitHub API: OK才算真正通了
composer config --global 配了却还报限速？常见失效场景
Token 配了≠生效。以下情况会让 Composer 继续走未认证通道：
- 运行
composer install的用户和执行composer config --global的不是同一个（比如用sudo安装，但 config 是普通用户配的） - 项目根目录下存在
auth.json，它会覆盖全局配置；用composer config --list查看实际生效位置 - token 已被 GitHub 删除或过期（classic token 默认永不过期，但 fine-grained token 有明确有效期）
- PHP 禁用了
curl或 SSL 验证失败（尤其某些旧版 CentOS），导致 Authorization 头根本发不出去
为什么必须用 github-oauth.github.com 而不是环境变量
Composer 不读 GITHUB_TOKEN 或 GITHUB_PAT 这类通用环境变量。它只认自己定义的配置项：
-
github-oauth.github.com是硬编码在 Composer 源码里的键名，对应 GitHub API 域名 - 如果误配成
github-oauth.api.github.com或漏掉.com，Composer 会完全无视 - 也不支持通配符，
github-oauth.*.github.com无效 - 想批量配多个域名（如 github.enterprise.com），得单独为每个域名 run 一次
composer config --global
最容易被忽略的是 auth.json 文件权限和用户上下文一致性——这两个点不检查，配了 token 也等于白配。
