为什么配了 GitHub Token 还报 403 rate limit exceeded

不是 token 没生效，而是请求根本没走到 GitHub API——代理池调度策略错配导致 Composer 绕过认证通道，直连 api.github.com 走匿名限流池。常见于公司级代理或自建镜像服务未正确透传 Authorization 头，或配置了 http-proxy 却漏掉 https-proxy，结果 HTTPS 请求被降级为未认证直连。

• 验证方式：加 -v 运行 composer install，搜日志里是否出现 Using GitHub token from configuration；没出现就是代理拦截或配置错位
• 代理必须同时支持 HTTP 和 HTTPS，并显式转发 Authorization: Bearer xxx 头（很多企业代理默认 strip 掉敏感头）
• 若用 Nginx 或 Squid 做反向代理，需确认 proxy_pass_request_headers on; 且未在 proxy_hide_header 中屏蔽 Authorization

中文环境下的代理池选型与 Composer 兼容性

国内常用代理池（如阿里云镜像、腾讯云 TKE 镜像、私有 Packagist 部署）本质是缓存层，不代理 GitHub API 请求——它们只加速 packagist.org 的元数据拉取，但无法绕过 Composer 对 GitHub 仓库的直接 API 调用（比如解析 dev-main 分支、获取 commit hash）。所以“换镜像”不能替代 GitHub Token。

GitHub Actions Runtime Regression Audit

对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。

下载

• composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/ 只影响 packagist.org 数据源，不影响 GitHub API
• 真正能调度 GitHub 流量的是带认证透传能力的 HTTP 代理（如 Caddy + forward_proxy 插件），而非纯缓存镜像
• CI 环境中若用 GitHub Actions，GITHUB_TOKEN secret 默认不自动注入到 Composer 请求头，必须手动执行 composer config --global github-oauth.github.com ${{ secrets.GITHUB_TOKEN }}

如何让 Composer 在代理池中仍走认证通道

关键不是“让代理池处理限流”，而是“让 Composer 的请求始终携带 token 并被代理正确转发”。这需要三者对齐：Composer 配置、代理行为、网络路径。

• Composer 必须用 github-oauth.github.com（注意域名是 github.com，不是 api.github.com），否则认证信息不匹配
• 代理配置中 https-proxy 的 URL 必须以 https:// 开头，且证书可信（自签名证书需额外设 config.ssl.no-verify-peer true）
• 若代理池做了域名重写（例如把 github.com 映射到内网镜像地址），则 Composer 会跳过 token 注入逻辑——因为 host 不匹配
• 临时验证：运行 curl -H "Authorization: Bearer ghp_xxx" https://api.github.com/rate_limit 看返回的 rate.limit 是否为 5000

auth.json 权限和 CI 环境中的静默失效点

权限错误是最常被忽略的失效原因。Composer 在 Linux/macOS 下读取 ~/.composer/auth.json 前会先检查文件权限，一旦不是 600 就直接跳过，不报错、不提示，静默退回到未认证模式。

• 执行 chmod 600 ~/.composer/auth.json 后再试，别信 “文件刚生成时默认就是 600”
• CI 中若用 Docker，auth.json 往往挂载进容器，但 UID/GID 不匹配会导致权限校验失败（比如宿主机 UID=1000，容器内默认 UID=0）
• Windows 下无权限问题，但要注意路径：%APPDATA%\Composer\auth.json，且不能用 WSL 的 ~/.composer 路径混用
• 多项目共用代理池时，不要依赖单个项目里的 auth.json，全局配置才是唯一可靠路径

GitHub API 认证不是开关式配置，而是一条从 Composer 内部 token 注入、到 HTTP 头构造、再到代理透传、最后抵达 GitHub 服务端的完整链路。任一环节断开，都会回落到每小时 60 次的匿名限额——而且这个过程没有任何明确报错，只有卡住或 403。