Composer仅通过~/.composer/auth.json（或COMPOSER_AUTH）中"github-oauth":{"github.com":"token"}格式凭据认证GitHub API，用于突破60次/小时限流并访问私有库，其他方式如环境变量、composer.json配置均无效。
Composer 本身不支持“配置 GitHub Token”这种全局设置，它只在访问私有仓库或触发 GitHub API 限流时被动使用 auth.json 中的凭据——Token 必须以特定格式写入该文件，且仅对 github.com 生效；直接在命令行传 Token、改 composer.json 或设环境变量都无效。
为什么 Composer 需要 GitHub Token
GitHub 对未认证请求限制为每小时 60 次，而 Composer 安装依赖时频繁调用 API（如获取 tag、commit hash、私有 repo 元数据），极易触发 403 rate limit exceeded。Token 认证后升至每小时 5000 次，并解锁私有仓库访问权限。
- 仅影响通过 GitHub API 获取元数据的场景（
composer install、update时解析composer.json中的"type": "package"或 Git repos） - 不影响已缓存的 dist 包下载（zip/tar.gz），也不影响 Packagist.org 上的公开包
- Token 权限只需勾选
public_repo（私有库则加repo），无需delete_repo等高危权限
正确写入 auth.json 的位置和格式
auth.json 必须放在 Composer 的配置目录下（不是项目根目录），且结构严格限定为 {"github-oauth": {"github.com": "你的token"}}。路径因系统而异：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Linux/macOS：
~/.composer/auth.json - Windows：
%APPDATA%\Composer\auth.json
示例内容（注意双引号、无逗号结尾、无多余空格）：
{
"github-oauth": {
"github.com": "ghp_xxx..."
}
}
- 如果项目级需要不同 Token（如 CI 环境），可将
auth.json放在项目根目录，再通过COMPOSER_AUTH环境变量指向它：COMPOSER_AUTH='{"github-oauth":{"github.com":"ghp_..."}}' composer install - 不要用
composer config --global github-oauth.github.com xxx—— 这条命令会错误地把 Token 写进config.json，完全不生效 - Token 泄露风险高，禁止提交到 Git。建议 CI 中用 secret 注入，本地用
chmod 600 ~/.composer/auth.json限制读取
验证是否生效及常见失败原因
运行 composer diagnose 会提示 “GitHub API is operational”，但更可靠的是触发一次真实 API 调用：
- 临时删掉一个已安装的包，执行
composer require monolog/monolog:dev-main（强制走 GitHub API 查 commit） - 若看到
Cloning into '/path/to/vendor/monolog/monolog'且无 403 报错，说明 Token 已生效 - 常见失败：Token 过期（GitHub token 默认永不过期，但用户可能手动 revoke）、
auth.json路径错（Composer 不会报错，只是静默忽略）、JSON 格式非法（多一个逗号或少引号，Composer 会报file could not be loaded）、Token 权限不足（私有库没勾repo）
真正麻烦的不是配置步骤，而是 Composer 对凭证的加载逻辑极其隐晦：它只认固定路径 + 固定字段名 + 固定域名键名，任何偏差都会降级回匿名请求。别信网上那些改 composer.json 或设 GITHUB_TOKEN 环境变量的方案——它们对 Composer 的 GitHub API 调用完全无效。
