为什么配了 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。
-
composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/只影响 packagist.org 数据源，不影响 GitHub API - 真正能调度 GitHub 流量的是带认证透传能力的 HTTP 代理（如 Caddy + forward_proxy 插件），而非纯缓存镜像
- CI 环境中若用 GitHub Actions，
GITHUB_TOKENsecret 默认不自动注入到 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，全局配置才是唯一可靠路径
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
