Composer如何配置GitHub认证_OAuth认证对接要点
为什么composer config -g github-oauth.github.com必须加-g
很多开发者踩的第一个坑就在这里：如果不加-g，token会被写入当前项目的composer.json配置文件里。问题在于，Composer在解析依赖元数据时——比如从Packagist获取某个包对应的GitHub仓库最新标签——根本不会去读取项目级的配置。这时候，所有的API请求都会以匿名身份发出，结果可想而知：GitHub API每小时60次的限额瞬间就会被用完。
加上-g参数，token才会被写入全局的~/.composer/auth.json文件。这个文件在Composer启动初期就会被加载，其认证信息会覆盖整个安装或更新流程，无论是抓取Packagist元数据、递归解析依赖，还是发现私有仓库地址，所有环节的GitHub API调用都能顺利通过。
composer config github-oauth.github.com xxx→ 错误做法。仅影响当前项目，且在关键阶段无效。composer config -g github-oauth.github.com xxx→ 正确做法。全局生效。composer config --global github-oauth.github.com xxx→ 与-g等价，但注意别把--global拼写成--gloabal这类笔误。
github-oauth.github.com权限到底要勾哪些
只勾选public_repo权限看似足够，但实际操作中，大部分认证失败恰恰就卡在这个环节。当Composer需要拉取fork的包、解析Git子模块，或者某些公开包的composer.json里嵌套了指向私有源的repositories配置时，都会触发对repo权限范围的校验。系统给出的错误提示往往是模糊的403 Forbidden或404 Not Found，而不是直接告诉你权限不足。
因此，权限必须勾选到位：repo（包括其下的所有子项，如repo:status、repo_deployment等）以及read:packages（如果使用了GitHub Packages）。至于delete:packages或admin:org这类高危权限，则完全不需要。
- 传统的classic token正逐步被弃用，优先选择功能更细粒度的fine-grained token，并将其资源范围限定在
github.com或具体的仓库上。 - 给token命名时建议带上用途，例如
composer-global-2026，方便日后在GitHub设置页面快速定位和管理。 - 生成token的页面一旦关闭，明文就无法再次查看，复制时务必注意别带上多余的空格或换行符。
CI环境里千万别写死token到auth.json
在GitHub Actions、GitLab CI这类持续集成环境中，如果直接运行composer config -g命令，token会以明文形式写入~/.composer/auth.json文件。一旦日志级别设置为debug，或者runner配置不当，这个token就存在泄露风险。更安全的做法是绕过文件写入，直接使用COMPOSER_AUTH环境变量。
以GitHub Actions为例，正确的写法是：
COMPOSER_AUTH='{"github-oauth":{"github.com":"'"${{ secrets.GITHUB_TOKEN }}"'}}' composer install
这里需要注意单双引号的嵌套：外层使用单引号防止shell展开，中间的"${{ secrets.GITHUB_TOKEN }}"则由Actions平台自动注入并处理好转义。
- 在GitLab CI中，可以设置
GITHUB_TOKEN变量，然后使用类似命令：COMPOSER_AUTH='{"github-oauth":{"github.com":"'$GITHUB_TOKEN'"}}' composer install。 COMPOSER_AUTH环境变量的优先级高于auth.json文件，因此无需清理旧文件。- 不必特意从
.gitignore中删除auth.json——它默认就在忽略列表里，手动删除反而可能导致本地调试失效。
auth.json权限不对也会导致认证失败
即使token正确、-g参数没漏、权限也勾全了，还有一个隐蔽的陷阱：如果~/.composer/auth.json文件的所有者不是当前运行composer命令的用户，或者文件权限大于600，Composer出于安全考虑会直接拒绝读取。这时，系统会抛出Could not authenticate against github.com错误，你甚至没机会验证token本身是否正确。
修复命令很简单：
chown $USER:$USER ~/.composer/auth.json
chmod 600 ~/.composer/auth.json
这种情况通常有两种诱因：第一次配置时使用了sudo composer，导致文件所有者变成了root；或者手动复制了他人的auth.json文件，却忘了修改权限。
- 运行
ls -l ~/.composer/auth.json命令确认，输出应类似于-rw------- 1 youruser youruser。 - 如果项目本地的
composer.json文件里也配置了config.github-oauth，同时全局auth.json也存在，那么项目级的配置优先级更高，这有时会掩盖真正的全局配置问题。
说到底，真正让人头疼的往往不是“如何配置”，而是“配置了却不生效”。问题的根源，多半出在权限、作用域、环境变量展开方式这些细节没有对齐。尤其是在CI环境中，token不是贴进去就万事大吉，必须确保它在Composer进程启动的那一刻，就已经存在于正确的认证上下文中，而不是静静地躺在某个文件里等待被忽略。
