Composer 报 GitHub API 访问失败是因未认证请求触发每小时60次限流，需配置含 repo 权限的 GitHub OAuth Token 到全局 auth.json，否则仍会 403 或静默失败。
为什么 Composer 会报 GitHub API 访问失败？
因为 GitHub 自 2021 年起对未认证的 API 请求做了严格限流（每小时 60 次），而 Composer 在安装或更新包时频繁调用 https://api.github.com/ 查询仓库元数据、下载 ZIP、检查 tag 等，一旦超出限额就会返回 403 Forbidden 或 API rate limit exceeded 错误。
这不是网络问题，也不是 Composer 本身故障，而是 GitHub 强制要求身份标识 —— 即使你只是 `require` 一个公开包，也得带上合法凭证。
如何配置 GitHub OAuth Token？
Token 必须是用户级 Personal Access Token（PAT），且至少勾选 repo 权限（public_repo 不够，私有仓库同步和某些元数据操作需要完整 repo）。
- 访问
https://github.com/settings/tokens/new创建新 token，名称建议写composer-cli - 勾选
repo（不是public_repo），其他权限按需，但delete_repo这类高危项不要开 - 生成后立刻复制保存 —— 页面关闭后无法再次查看明文
- 在终端执行：
composer config -g github-oauth.github.com <your_token_here></your_token_here>
执行后，Composer 会把 token 写入全局配置文件（通常是 ~/.composer/auth.json），后续所有项目都会自动携带该认证头。
智能分析 Git 仓库或普通链接，自动识别内容类型并执行相应处理流程。 支持四种类型：1) OpenClaw Skills 项目（风险检测与收藏）2) 论文/文档项目（加入 dashifu——wiki 待处理队列）3) 功能项目（评估 OpenClaw 学习可行性）4) 普通网页/文章（加入 dashifu——w...
常见踩坑点：Token 权限、作用域与配置位置
错误配置比没配置更麻烦 —— 它会让你误以为“已经好了”，结果还是 403。
- 用了
public_repo权限 → 无法读取 private fork 的依赖信息，某些包的dist下载会静默失败 - 把 token 写在项目级
auth.json里但没加--auth参数 → Composer 默认只读全局配置 - token 过期或被手动删除 → 错误提示仍是
rate limit，实际是401 Unauthorized，需用curl -H "Authorization: token xxx" https://api.github.com/rate_limit手动验证 - 公司网络走代理且拦截了
Authorization头 → token 被丢弃，现象同未配置
替代方案：用 GitHub Packages Registry 替代直接访问 API？
不推荐。GitHub Packages 的 Composer registry（https://npm.pkg.github.com）仅支持 composer install 时拉取已打包的 .zip，但绝大多数 PHP 包并未发布到该 registry；它也不能替代 Packagist 对 GitHub 仓库的实时元数据解析，所以不能解决 composer update 卡在 API 请求的问题。
真正能绕过 API 限流的只有两个办法：配好 OAuth Token，或改用 Git 方式下载（设 composer config -g prefer-stable true + composer config -g use-github-api false），但后者会导致首次安装变慢、无法利用 GitHub 的 CDN 加速，且部分私有仓库策略会拒绝 Git clone。
Token 是目前最稳定、最低侵入性的解法，只要别把它硬编码进项目 auth.json 提交到仓库里就行。
