Composer底层通信：解析Composer如何与GitHub API交互-composer-PHP中文网

composer 必须配置 github oauth token 才能解决“api rate limit exceeded”错误：执行 composer config --global github-oauth.github.com 将含 repo 权限的 token 写入全局 auth.json（权限 600），否则依赖解析时主动调用 api.github.com 的未认证请求会触发每小时 60 次限流。

composer底层通信：解析composer如何与github api交互

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></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” 是否出现。

Git Factory

为每个编码任务配置并管理独立的 Git worktree，支持并行分支和清晰的 PR 工作流，避免合并冲突。

下载

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></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 必须全局、精确、有效，缺一不可。