Composer 必须配置 GitHub OAuth Token 才能解决“API rate limit exceeded”错误：执行 composer config --global github-oauth.github.com <token> 将含 repo 权限的 token 写入全局 auth.json（权限 600），否则依赖解析时主动调用 api.github.com 的未认证请求会触发每小时 60 次限流。
Composer 本身不直接“调用” GitHub API，而是通过 Packagist 的元数据索引间接触发 GitHub API 请求；真正撞上 403 rate limit exceeded 的环节，是 Composer 在解析依赖时主动向 api.github.com 发起的未认证请求 —— 这部分无法绕过，必须配 token。
Composer 哪些操作会真实发起 GitHub API 请求
不是所有 composer install 都走 GitHub API。只有当依赖源明确指向 GitHub（比如 "type": "package" + "source" 是 git URL，或包在 Packagist 上标记为 GitHub 托管且需动态查 tag），Composer 才会主动调用 api.github.com 获取元数据。
-
composer update时解析dev-main、dev-feature/x等分支：它要查最新 commit hash 和composer.json内容，走GET /repos/{owner}/{repo}/contents/composer.json?ref=... - 依赖中含 fork 后未改
source的包：Packagist 记录的是原仓库，但 Composer 拉取时发现 tag 不一致，会 fallback 到 GitHub API 查 fork 的 tag 列表 - 私有 GitHub 仓库（
repositories中配置了"type": "vcs"+"url": "git@github.com:..."）：即使用了 SSH URL，Composer 仍先走 HTTPS API 检查composer.json是否存在、是否可读 -
composer create-project拉取非稳定版（如dev-develop）：它不从 dist zip 下载，而是 clone 前先查 ref，触发 API
注意：composer install 从 composer.lock 安装已知版本时，若对应 dist URL 可用（比如 dist.zip），则完全不碰 GitHub API —— 所以限流问题多出现在 update 或首次 install 场景。
为什么配了 token 还报 403 或 401
Token 配了 ≠ 被用了。Composer 对认证域名匹配极其严格，且只在特定阶段加载配置。
- 域名必须是
github.com，不是api.github.com或www.github.com——composer config -g github-oauth.api.github.com <token>是无效的，得删掉重配成github.com - 全局配置（
-g）写入~/.composer/auth.json，但该文件权限必须是600（chmod 600 ~/.composer/auth.json），否则 Composer 静默忽略整份文件 - 项目根目录下存在
auth.json会覆盖全局配置 —— 如果里面写了空的"github-oauth": {}或错误的 token，就会导致认证失败 - CI 环境（如 GitHub Actions）中，
${{ secrets.GITHUB_TOKEN }}是短期 token，不能直接写进auth.json；必须在 job 开头运行composer config -g github-oauth.github.com "${{ secrets.GITHUB_TOKEN }}"
验证是否真生效：运行 composer config -g github-oauth.github.com，应输出 token 前几位（掩码格式）；再执行 composer diagnose，看 “GitHub API: OK” 是否出现。
GitHub Enterprise 或私有 Git 实例怎么配
GitHub.com 的 token 对 git.company.internal 或 github.company.com 完全无效 —— Composer 不做子域继承，只做精确 host 匹配。
- 生成 token 必须去你的 GHE 实例地址（如
https://git.company.internal/settings/tokens/new），权限勾选repo - 配置命令必须用实际 API 域名：
composer config -g github-oauth.git.company.internal <token>（端口也要带上，如git.company.internal:8443） -
composer.json中的repositories必须也指向同一 host，例如：{"type": "vcs", "url": "https://git.company.internal/owner/repo.git"} - 若启用了 SAML SSO，token 需额外在网页上授权（弹窗确认），否则仍返回 403
别试图用 github.com 的 token 覆盖所有 GitHub 相关域名 —— Composer 的 auth 匹配逻辑就是字符串精确比对，没有通配或 fallback。
为什么不能靠改 Packagist 镜像或换 dist 源解决
Packagist 镜像（如阿里云、腾讯云）只缓存 packages.json 和 dist zip，不代理 GitHub API 请求。Composer 解析依赖链时，仍需实时调用 api.github.com 获取 fork 仓库的 tag、分支、composer.json 内容等动态信息。
- 设
composer config -g prefer-dist true只影响下载方式（zip vs git clone），不影响元数据查询阶段 - 把包发布到 GitHub Packages Registry（
npm.pkg.github.com）也不能替代 GitHub API —— 它只提供已打包的 dist，不支持composer update时的版本发现和分支解析 - 唯一能避开 GitHub API 的办法，是彻底不用 GitHub 托管源码（比如迁移到 GitLab 并配其 token），或所有依赖都锁定稳定版并确保
composer.lock中的 dist URL 可用
真正关键的点在于：GitHub API 请求发生在依赖解析早期，且由 Composer 主动发起，不是可选路径 —— 所以 token 必须全局、精确、有效，缺一不可。
