Composer如何排查token失败_Composer认证排错分析思路【汇总】-composer-PHP中文网

composer github-oauth 配置生效的直接验证方式是运行 composer config -g github-oauth.github.com，输出应为 token 前几位（如 ghp_abc123...），不能为空、null 或报错；域名必须严格为 github.com，且需执行 composer clear-cache 清除旧认证缓存，再用 -vvv 查看日志中是否出现 “using github oauth token”。

composer如何排查token失败_composer认证排错分析思路【汇总】

Composer 认证失败不是网络或权限配置错，而是凭证没写对、没生效、或被缓存了旧状态——先验证 token 是否真实写入，再确认它是否被 Composer 实际使用。

如何确认 github-oauth 配置已生效

Composer 不会报错提示 “你配错了”，它只会静默跳过无效配置。最直接的验证方式是查当前值：

运行 composer config -g github-oauth.github.com，输出应为 token 的前几位（如 ghp_abc123...），不能是空、null 或报错
若输出为空，说明没配成功；若带多余空格或换行，token 会被截断失效
注意域名必须是 github.com，不是 api.github.com 或 www.github.com —— 写错就完全不触发 OAuth 流程
该配置只影响 HTTPS 协议的 GitHub 请求；如果 composer.json 里仓库 URL 是 git@github.com:...，Composer 根本不会读这个 token，而是交由 Git 走 SSH

为什么 new token 还是报 Could not authenticate

常见原因是 Composer 缓存了上次失败的 401 响应，新 token 不会自动覆盖。哪怕你改了 auth.json 或执行了 composer config，只要缓存没清，错误照旧。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

必须执行 composer clear-cache，这是硬性步骤，不是“可选优化”
清除后建议加 -vvv 参数重试：例如 composer install -vvv，观察日志中是否出现 Using GitHub OAuth token
若日志里仍有 Failed to download ... Invalid credentials，说明 token 没被用上，回头检查上面的域名和格式
GitHub 的 fine-grained token 在多数 Composer 版本中不被支持，必须用 classic token（页面上明确标有 “Classic” 标签）

auth.json 和 github-oauth 配置冲突怎么办

两者可以共存，但优先级不同：github-oauth 是全局快捷方式，专用于 GitHub；auth.json 更通用，支持任意域名的 HTTP Basic 或 Bearer 认证。容易出问题的是路径和结构。

auth.json 必须放在 Composer 全局配置目录下：~/.composer/auth.json（Linux/macOS）或 %APPDATA%\Composer\auth.json（Windows），项目根目录下的同名文件默认不读
JSON 格式极其敏感：http-basic 不能写成 http_basic，字段名大小写错一个字母，整段配置就被忽略
如果同时配了 github-oauth.github.com 和 auth.json 里的 https://github.com，前者优先；但若前者为空或无效，Composer 不会 fallback 到后者
CI 环境中建议统一用环境变量注入，比如 composer config http-basic.github.com $GITHUB_USERNAME $GITHUB_TOKEN，避免依赖本地文件