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 实际使用。
如何确认 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，避免依赖本地文件
真正卡住的地方往往不是 token 本身，而是 Composer 没走到 token 验证那步——比如仓库 URL 是 SSH 格式却去调 GitHub OAuth，或者镜像源把私有包请求转发到了公开源。验证时盯住 -vvv 日志里实际发起的请求 URL 和认证头，比猜更可靠。
