是token失效而非网络或composer故障，主因是auth.json中github token被revoke、fine-grained过期或sso授权撤回，表现为downloading卡住、401 unauthorized或failed to download，可用curl验证有效性。
Composer install 卡在 Downloading 就是 Token 过期了？先别重装
不是网络慢，也不是 Composer 坏了，是 auth.json 里存的 GitHub Token 已失效——常见于 classic PAT 被 revoke、fine-grained token 到期、或 SSO 授权被撤回。报错未必明说 “token expired”，而是卡住、Failed to download、或直接 401 Unauthorized。
关键判断点：composer show vendor/private-package 能查到包但 install 失败，基本可锁定为认证环节问题，而非包本身不存在。
怎么确认当前 Token 还有效？别靠猜
手动 curl 是最直接的验证方式，绕过 Composer 缓存和配置逻辑：
- 从
auth.json中取出github-oauth.github.com对应的值（用composer config -g github-oauth.github.com查） - 执行：
curl -H "Authorization: Bearer ghp_xxx..." https://api.github.com/user/repos?per_page=1 - 返回
401或{"message":"Bad credentials"}→ Token 已废 - 返回正常 JSON（哪怕空数组）→ Token 有效，问题在别处（比如域名不匹配、SSO 未授权）
注意：别用 npm.pkg.github.com 地址测试——那是 Packages registry，认证走的是 github.com 域名，不是 registry host。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
自动化预警能做啥？实际能落地的三件事
完全自动续期不现实（GitHub 不提供刷新接口），但可提前发现 + 快速响应：
- 每天定时跑
composer diagnose --no-interaction 2>&1 | grep -q "token has expired"，有输出就发钉钉/邮件告警 - 检查
~/.composer/auth.json里 token 长度是否为 40 位（classic）或 52+ 位（fine-grained）——若长度异常（如 32 位），大概率是旧版 OAuth token，已停用 - 结合 GitHub API 检查 token 状态：
curl -H "Authorization: Bearer $TOKEN" https://api.github.com/applications/octocat/tokens/$TOKEN 2>/dev/null | jq -r '.name // "invalid"'，返回invalid即失效
这些脚本要避开 shell 历史泄露 token：所有含 token 的命令必须用变量传参，且变量定义前加 unset TOKEN 清理；别把 token 写进 cron 脚本明文里。
为什么预警后手动修复还失败？三个静默坑
Token 更新了，但 Composer 仍发旧头，原因往往藏在配置细节里：
-
auth.json域名写成https://github.com或api.github.com→ Composer 直接忽略整段，fallback 到无认证 - 用了 fine-grained token 却没勾选
administration（私有 repo 需要）或read:packages（Packages 场景）→ 权限不足等同于无效 - CI 环境里
composer config --global写入的 token 被缓存层污染，或容器每次启动都重置~/.composer→ 必须在构建阶段重新注入
真正生效的只有 composer config --global github-oauth.github.com <new_token></new_token> 这一条命令的结果，其他任何手改 auth.json 的方式都容易漏掉 JSON 格式、权限（600）、或 shell 特殊字符转义问题。
