配 github oauth token 是为了让 composer 调用 github api 时认证，将请求限额从每小时 60 次提升至 5000 次，避免 fetch commit、查 tag 等元数据请求因 403 rate limit exceeded 或静默超时而失败。
配 GitHub OAuth Token 不是为了“登录 GitHub”，而是让 Composer 在调用 https://api.github.com/ 时带上 Authorization: Bearer xxx 头，把每小时 60 次的匿名限额拉到 5000 次——不配，composer install 就卡在 fetch commit、查 tag、读 composer.json 这些元数据请求上，报 403 rate limit exceeded 或静默超时。
为什么 composer config -g github-oauth.github.com 是唯一可靠入口
GitHub API 元数据请求发生在依赖解析早期，此时项目目录下的 auth.json 或 composer.json 都还没加载。只有全局配置能覆盖整个链路。
-
-g（即--global）不可省略，否则会写进当前项目的composer.json的config字段，极易误提交到 Git - host 名必须是
github.com，不是api.github.com、www.github.com或其他变体，Composer 只认这个域名 - 命令执行后，token 存在
~/.composer/auth.json（Linux/macOS）或%APPDATA%\Composer\auth.json（Windows），别手动编辑它——JSON 格式错一个逗号，Composer 就静默跳过认证
Token 必须是 classic 类型且带 repo 权限
截至 2026 年中，Composer 仍不兼容 fine-grained token，后者会静默失败；classic token 也必须勾选 repo（含 public_repo），否则私有库、fork 仓库、甚至某些公开包的元数据都拿不到，报 401 Could not authenticate 而非限流提示。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 去
https://github.com/settings/tokens/new生成 classic token - 填写 Note（如
composer-token-2026），过期时间建议设为 30 天 - 只勾选
repo和read:packages（后者仅当你用 GitHub Packages 时需要） - 生成后立刻复制——页面关闭就再也看不到原始值
验证是否真生效，别只看有没有报错
很多用户执行完 composer config -g github-oauth.github.com 就以为搞定了，结果 composer install 还是慢或失败。真正要确认的是 Composer 是否在发请求时用了 token。
- 运行
composer diagnose，末尾应显示GitHub API: OK，且rate limit显示为5000；若仍是60，说明 token 没生效 - 临时删掉 token，再跑
composer show monolog/monolog -vvv 2>&1 | grep 'api.github.com'，能看到大量403响应；加回 token 后应返回200 - Linux/macOS 上检查
~/.composer/auth.json权限：必须是600（chmod 600 ~/.composer/auth.json），否则 Composer 拒绝读取
最容易被忽略的点是：token 本身没问题，但 Composer 没走认证通道——比如你同时用了 Packagist 镜像源、启用了 http-basic 认证、或 CI 环境里用 COMPOSER_AUTH 环境变量覆盖了全局配置，这些都会让 token “存在但没用上”。
