需配置GitHub个人访问令牌（PAT）到全局auth.json：运行composer config -g github-oauth.github.com ，确保令牌勾选repo和read:packages权限，并设auth.json权限为600。
composer install 报错 “API rate limit exceeded” 怎么办
这是没配 GitHub 令牌的典型表现，Composer 在拉取私有库或高频访问 GitHub 公共库时，会触发未认证请求的限流（60 次/小时）。配了 github-oauth 后，走的是认证 API，上限升到 5000 次/小时。
- 令牌必须是个人访问令牌（PAT），不是 SSH key 或 OAuth App token
- 创建时至少勾选
repo（读私有库）和read:packages（读 GitHub Packages），如果只装公开包，public_repo也够用 - 别把令牌硬编码进
composer.json—— 它会被提交到 Git，属于严重安全风险 - 令牌应存在本地配置里，对所有项目生效：
composer config -g github-oauth.github.com <your_token_here>
为什么 composer config github-oauth 不加 -g 无效
不加 -g 是给当前项目写入 composer.json 的 config.github-oauth 字段，但 Composer 从 2.2 开始默认忽略该字段 —— 它只认全局配置或环境变量 GITHUB_TOKEN。
- 加
-g写入的是~/.composer/auth.json，这才是 Composer 实际读取的位置 - 如果项目用了
COMPOSER_AUTH环境变量，它优先级更高，会覆盖auth.json - 检查是否生效：运行
composer config -g --list | grep github-oauth，有输出才算成功
GitHub 令牌失效后 composer 仍卡在旧错误
不是缓存问题，是 Composer 尝试重试时用了旧凭据，而 GitHub 返回 401 后它不会自动清掉失败凭据。你得手动清理并重试。
- 删掉
~/.composer/auth.json里对应github.com的条目，或整文件删掉再重配 - 删掉
vendor/和composer.lock（尤其锁文件里可能存了已鉴权的 dist URL） - 执行
composer clear-cache，避免旧元数据干扰 - 再跑
composer install，它会重新发起带新令牌的请求
CI 环境下怎么安全传入 GitHub 令牌
不能写死在脚本里，也不能塞进 auth.json 提交到仓库。正确做法是靠环境变量注入，且确保 CI 日志不回显。
- GitHub Actions：用
secrets.GITHUB_TOKEN（自带）或自定义 secret，配合composer config github-oauth.github.com ${{ secrets.MY_TOKEN }} - GitLab CI：设变量为
GITHUB_TOKEN，Composer 会自动识别并用于认证 - 自建 Jenkins：通过 Credentials Binding 插件注入环境变量，禁止勾选 “Mask passwords in logs” 以外的选项
- 验证是否生效：CI 中加一步
composer config --global --list | grep github-oauth，确认输出非空
auth.json 文件权限要是 600，否则 Composer 会拒绝读取。 
