Composer需配置GitHub/GitLab Token防API限流：GitHub用composer config -g github-oauth.github.com <token>，GitLab用composer config -g http-basic.gitlab.com <user> <token>；Token明文存于auth.json，应加入.gitignore；验证需清缓存并重装依赖。

Composer config 怎么加 GitHub Token

直接在全局或项目级配置里写入 github-oauth，否则 Composer 会频繁触发 API 限流（每小时 60 次未认证请求），导致 composer install 卡住或报 Could not fetch https://api.github.com/... 错误。

• 生成 Token：GitHub → Settings → Developer settings → Personal access tokens → Generate new token，勾选 repo（私有库必需）和 read:packages（如果用 GitHub Packages）
• 执行命令：composer config -g github-oauth.github.com <your_token_here>（-g 是全局；去掉就是当前项目）
• Token 会明文存进 ~/.composer/auth.json，别把这个文件提交到 Git —— 建议加进 .gitignore
• 验证是否生效：删掉 vendor 和 composer.lock，再跑一次 composer install，看是否跳过登录提示且不报 403

GitLab Token 配置为什么总失败

GitLab 不走 github-oauth 字段，必须用 http-basic + 正确的域和服务名匹配，否则 Composer 根本不会把 Token 带进 HTTP Header。

Discussion Composer

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

下载

• Token 类型选 personal_access_token，权限至少含 read_api 和 read_repository
• 配置命令不是 github-oauth，而是：composer config -g http-basic.gitlab.com <username> <token>（注意：域必须是 gitlab.com 或你自建 GitLab 的完整域名，比如 gitlab.example.org）
• 如果用的是 GitLab 私有包（type: package + dist 指向 .git 地址），确保 composer.json 里的 repositories URL 协议是 https，且域名和 http-basic 配置的域名完全一致（连端口都不能差）
• 常见错误：配了 http-basic.gitlab.com，但仓库 URL 写成 https://gitlab.com/group/project.git —— 看似一样，其实没问题；但如果写成 https://www.gitlab.com/... 就失效（域名不匹配）

Token 存哪里？能不能加密或换其他方式

auth.json 是唯一被 Composer 官方支持的凭据存储位置，不支持环境变量注入、密钥管理器集成或加密文件，强行绕开只会让依赖安装不可重现。

• 默认路径：~/.composer/auth.json（Linux/macOS），%APPDATA%\Composer\auth.json（Windows）
• 可以用 COMPOSER_AUTH 环境变量替代文件（值为 JSON 字符串），例如：export COMPOSER_AUTH='{"github-oauth": {"github.com": "xxx"}}' —— 适合 CI 环境，但本地开发容易漏设
• 别试图用 config.platform 或插件伪造认证逻辑，Composer 在网络请求阶段就解析 auth.json，中间层无法干预
• 如果公司强制要求凭据不落地，只能接受每次 composer install 手动输密码（对私有 Git 库），或者推动改用 SSH + deploy keys（需 Composer 配置 git@ URL 并确保 ssh-agent 可用）

为什么换了 Token 还是 401？检查这三处

Token 生效不是“配完就完”，实际请求时会受 Composer 版本、仓库类型、URL 协议三重影响，最容易忽略的是协议降级和缓存残留。

• 运行 composer diagnose，重点看 “Checking composer.json: OK” 后有没有警告 “The configured GitHub OAuth token has expired” 或 “No authentication configured for gitlab.com”
• 删掉 vendor、composer.lock，再清空 Composer 缓存：composer clear-cache（旧版本缓存可能存着 401 响应）
• 如果是私有 Packagist（如 Satis、Private Packagist），确认其 composer.json 中的 repositories type 是 composer，且该服务本身已配置好上游 Git 认证 —— Composer 只负责传 Token 给它，不负责替它去 Git 拉代码

Token 配置本身很简单，难的是它隐式生效、隐式失效；一旦出问题，错误信息往往指向网络或权限，而不是 auth.json 本身。多看 composer diagnose 输出，少猜。