需配置 GitHub Personal Access Token 解决 Composer 的 API 限流问题：生成带 repo 和 read:packages 权限的 token，执行 composer config -g github-oauth.github.com your_token_here 全局配置，可将限额从每小时 60 次提升至 5000 次。
Composer install/update 报错 “API rate limit exceeded” 怎么办
这是 GitHub 对未认证请求的限流触发——Composer 默认用匿名方式访问 GitHub API，每小时最多 60 次。一旦项目依赖多、或多人共用出口 IP（比如公司代理、CI 环境），很容易撞上这个限制。解决办法只有一个：让 Composer 带上你的 GitHub Personal Access Token 认证请求。
怎么生成并配置 GitHub Token 给 Composer 用
Token 必须带 repo 权限（读私有库需要）和 read:packages（如果用 GitHub Packages）。生成后不能再次查看明文，务必立刻复制保存。
配置方式推荐用全局凭证管理，执行以下命令（替换 your_token_here 为实际 token）：
composer config -g github-oauth.github.com your_token_here
这条命令会把 token 写进全局 auth.json（通常在 ~/.composer/auth.json），所有项目都会自动复用。不需要改每个项目的 composer.json，也不用手动写 auth.json 文件。
- 如果只想对单个项目生效，去掉
-g参数，且在项目根目录下运行 - token 泄露风险高，别提交到 Git；
auth.json默认被 Composer 加入全局 .gitignore，但手动创建的要自己加 - GitHub 已弃用密码登录 API，
username/password方式在 Composer 2.2+ 已不可用，必须用 token
验证 Token 是否生效 & 常见失效原因
运行 composer diagnose，看到类似输出说明已识别：
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
Checking github.com rate limit: OK
如果仍报限流，检查这几处：
- token 权限不全（尤其是没勾选
repo）→ 重新生成并确认勾选 - token 被误删或过期（GitHub Token 可设有效期，设为 “No expiration” 更省心）
- 公司网络走代理，但代理拦截或重写了 Authorization 头 → 换网络或联系运维
- CI 环境（如 GitHub Actions）用了
GITHUB_TOKENsecret，但没通过composer config注入 → 需显式执行配置命令
CI/CD 中自动注入 Token 的安全写法
在 GitHub Actions 或 GitLab CI 中，绝不能硬编码 token 到脚本里。正确做法是利用环境变量 + composer config 动态写入：
composer config -g github-oauth.github.com ${{ secrets.GITHUB_TOKEN }}
注意：
-
secrets.GITHUB_TOKEN是 Actions 自带的临时 token，权限足够且自动轮换，优先用它 - 自定义 secret（如
COMPOSER_GITHUB_TOKEN）需手动创建，且只在必要时使用（比如要访问其他 GitHub 组织的私有库） - Docker 构建中若分层缓存，
auth.json可能被意外打包进镜像 → 在构建最后一步写入，或用 multi-stage 隔离
Token 生效后，API 限额会从每小时 60 次升到 5000 次，但真正容易被忽略的是：某些老旧私有包仓库（比如用 GitHub Pages 托管的 dist 包）可能仍走匿名下载，这时限流提示会消失，但下载失败——得检查 composer.json 里的 dist URL 是否指向 raw.githubusercontent.com，那种链接不走 API，不受 token 影响，也无需认证。
