Composer install 报“API rate limit exceeded”是因为未认证的 GitHub API 请求超限（每小时60次），需配置 GitHub Personal Access Token：在 GitHub 生成带 repo 等权限的 token，再执行 composer config -g github-oauth.github.com 完成认证。
为什么 composer install 会报 “API rate limit exceeded”
GitHub 对未认证的 API 请求做了严格限制，每小时最多 60 次。Composer 在安装包时（尤其是从 github.com 的私有仓库或频繁访问 Packagist 元数据时）会调用 GitHub API 获取最新 commit、tag 或仓库信息。一旦超出限额，就会出现错误：Could not fetch https://api.github.com/...: Failed to decode response: json_decode() expects parameter 1 to be string, null given 或更直白的 API rate limit exceeded。
这不是 Composer 本身的问题，而是你没告诉它“你是谁”。默认走的是匿名请求，自然被限得死死的。
- 公共包偶尔失败，多试几次可能过——但 CI/CD 环境里大概率稳稳失败
- 私有仓库（哪怕已配置
repositories）也逃不掉，因为 Composer 仍需通过 GitHub API 校验 repo 存在性与权限 - 用
git@github.com:SSH 地址？没用。Composer 仍然会走 HTTPS + API 查询，SSH 只影响后续 clone 阶段
怎么让 composer 认证 GitHub 账号
核心就一条：把 GitHub Personal Access Token 写进 Composer 的全局认证配置里，让它每次发 API 请求都带上 Authorization: Bearer xxx 头。
操作分两步，缺一不可：
- 在 GitHub 上生成 token：Settings → Developer settings → Personal access tokens → Tokens (classic) → Generate new token → 勾选
repo（私有库必需）、read:packages、delete:packages（如果用 GitHub Packages）、write:packages（发布用），生成后**立刻复制保存**（页面刷新后不再显示） - 执行命令写入配置：
composer config -g github-oauth.github.com <your_token_here></your_token_here>（注意空格，不是等号） - 验证是否生效：
composer config -g github-oauth.github.com应该输出你的 token 前几位（Composer 会自动隐藏部分字符）
别手抖把 token 粘贴进 auth.json 手动编辑——容易格式错、引号漏、权限失控。用 composer config 命令最稳。
CI/CD 环境下 token 怎么安全注入
本地配一次能用，但 Jenkins/GitHub Actions/Docker 构建时，不能把 token 明文写进 composer.json 或脚本里。必须走环境变量 + 运行时注入。
- GitHub Actions：在 workflow 文件中用
COMPOSER_AUTH环境变量传入 JSON 字符串，例如：{"github-oauth": {"github.com": "${{ secrets.GITHUB_TOKEN }}"}} - Jenkins：用 Credentials Binding 插件注入环境变量，再在构建步骤中运行：
echo '{"github-oauth":{"github.com":"'$GITHUB_TOKEN'"}}' > ~/.composer/auth.json - Docker 构建：避免在
Dockerfile中用ARG硬编码 token；改用docker run -e COMPOSER_AUTH=...启动时注入
COMPOSER_AUTH 是 Composer 官方支持的环境变量，优先级高于 auth.json 和全局 config，且内容是完整 JSON 字符串，不用额外处理路径或格式。
token 权限不够或过期了会怎样
常见现象不是报错“token 无效”，而是退化回匿名请求——又见 API rate limit exceeded。尤其容易忽略两点：
- token 被删了或禁用了，但本地
composer config还存着旧值，命令查得到，实际请求 401 - 只勾了
public_repo，但项目依赖私有库，必须勾repo（含私有库读写） - GitHub 已停用密码登录，但有人误把账号密码当 token 用，结果一直 401
排查时直接 curl 测试最准：curl -H "Authorization: Bearer <your_token>" https://api.github.com/rate_limit</your_token>。返回里 rate.remaining 大于 0 才算真正生效。
token 不是设完就一劳永逸的，尤其团队共用一个 token 时，谁删了、谁改权限了、谁过期了，都会让整个构建链突然卡住。定期检查、专人维护、最小权限原则，比写十遍重试逻辑都管用。
