核心是凭证必须匹配请求域名且禁止提交至版本控制：auth.json须按项目根目录→全局路径顺序放置，github/gitlab需用专用字段（github-oauth、gitlab-token），https仓库url域名须与auth.json键名完全一致，ci环境应使用composer_auth环境变量。
Composer 私有仓库的访问令牌配置，核心就一条：凭证必须匹配请求域名，且不能出现在版本控制里。用错位置、填错域名、混用认证方式，都会导致 Authentication failed 或 404 Project Not Found。
auth.json 文件必须放对位置，且优先级要清楚
Composer 查找 auth.json 有固定顺序：先看项目根目录，再查全局路径（~/.composer/auth.json 或 %APPDATA%\Composer\auth.json）。项目级配置优先级更高，适合多项目用不同 token 的场景；全局配置省事，但所有项目共享同一套凭据。
- 项目级：直接在
composer.json同级目录新建auth.json，记得加进.gitignore - 全局级：运行
composer config --global http-basic.repo.example.com username token，自动写入全局配置 - 域名必须完全一致：比如仓库 URL 是
https://gitlab.internal.company/api/v4，那auth.json里 key 得写"gitlab.internal.company"，少个点或多了/api/v4都不认
GitHub/GitLab 要用专用字段，不能全塞进 http-basic
GitHub 和 GitLab 对 OAuth 认证做了特殊支持，硬塞进 http-basic 会失效。它们各自有专属字段：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- GitHub：用
github-oauth，key 必须是"github.com"（不是你的私有 GitHub Enterprise 地址） - GitLab：分两种情况：
• GitLab.com：用gitlab-oauth，key 是"gitlab.com"
• 私有 GitLab 实例（如gitlab.internal）：必须用gitlab-token，key 填完整域名，如"gitlab.internal" - 示例片段（GitLab 私有实例）：
{ "gitlab-token": { "gitlab.internal": "glpat-xxxxxx" } }
HTTPS 仓库 URL 写法决定你该用哪种认证机制
URL 格式和认证方式必须对得上，否则 Composer 根本不会把 token 带过去：
- SSH 地址（
git@gitlab.internal:group/repo.git）→ 不走 HTTP 认证，依赖系统 SSH agent 或~/.ssh/config，auth.json完全无效 - HTTPS 地址（
https://gitlab.internal/group/repo.git）→ 必须配http-basic或gitlab-token，且域名要和 URL 主机名完全一致 - HTTPS + Token 写在 URL 里（
https://oauth2:glpat-xxx@gitlab.internal/group/repo.git）→ 可行但不推荐，token 会出现在composer.lock和日志里，有泄露风险
CI/CD 环境别碰 auth.json 文件，改用 COMPOSER_AUTH
服务器或容器里写死 auth.json 文件容易被误提交或权限失控。生产环境强烈建议用环境变量：
- 设置
COMPOSER_AUTH环境变量，值为完整 JSON 字符串：export COMPOSER_AUTH='{"gitlab-token": {"gitlab.internal": "glpat-xxxxxx"}}' - 确保变量在
composer install运行时已生效（例如 GitHub Actions 中用env:块注入） - 注意 shell 转义：单引号包裹整个 JSON，内部双引号保留，避免被 shell 解析破坏结构
最容易被忽略的是域名匹配粒度——不是“能连上就行”，而是 Composer 会严格比对 HTTP 请求 Host 头和 auth.json 里的 key。哪怕只差一个端口号（:8080），或者用了 CNAME 别名，都会掉进认证黑洞。调试时用 composer install -vvv 看实际发起的请求 Host 是什么，再反推 auth.json 该填啥。
