Composer认证报错本质是凭证未被识别，而非密码错误；主因是auth.json路径错误、域名key不匹配或URL格式不符，它静默跳过而非报凭证无效。
认证报错本质是凭证没被识别，不是密码输错了
Composer 的 401/403 认证失败几乎从不因为“密码输错”，而是 auth.json 放错位置、域名 key 写错、或 URL 类型与认证方式不匹配。它不会提示“凭证无效”，只会静默跳过或报 Could not find package——你得主动验证是否真送出了凭证。
-
auth.json必须放在两个位置之一：~/.composer/auth.json（Linux/macOS）或%APPDATA%\Composer\auth.json（Windows），项目级则放项目根目录；放错路径等于没配 - GitHub 私有库的 key 必须是
github.com（不能是api.github.com或带 www），Bitbucket 必须是bitbucket.org，大小写和后缀都敏感 - 字段名必须是
http-basic，里面嵌套对象，结构为{"http-basic": {"github.com": {"username": "oauth2", "password": "ghp_xxx..."}}}；写成github-oauth或token字段会完全被忽略 - 如果用
composer config --global github-oauth.github.com xxx，它只影响 GitHub API 请求（如 fork 检测），不影响vcs类型仓库拉取——后者仍依赖auth.json
私有 Composer 仓库 403？先确认 URL 末尾有没有 /
对 type 为 composer 的私有源，URL 末尾必须带 /，否则 Composer 会拼出 https://your.repo/packages.json（缺斜杠）而不是 https://your.repo//packages.json（多一斜杠但能 fallback）。很多私有服务（如 Satis、Private Packagist）严格校验路径，缺斜杠直接返回 403 而非 404。
- 正确写法：
"url": "https://repo.example.com/"（结尾有/） - 错误写法：
"url": "https://repo.example.com"（无/），即使curl -I https://repo.example.com/packages.json能通，Composer 也可能因内部路径拼接失败而 403 - 验证方法：用
curl -v -u "user:pass" https://repo.example.com/packages.json看真实响应头；若返回HTTP/2 200且Content-Type: application/json才算真正可用
vcs 类型仓库认证失败？检查 .git 结尾和 token 权限
Git 类型仓库（"type": "vcs"）的认证失败，90% 出在 URL 格式或 token 权限上。GitHub 已停用密码认证，Bitbucket 推荐 App Password，GitLab 需 Personal Access Token 并勾选 read_repository。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- URL 必须以
.git结尾："url": "https://github.com/user/repo.git"；写成https://github.com/user/repo会导致 Composer 尝试走 GitHub API，而 API 不认auth.json里的http-basic凭证 - GitHub token 至少要勾选
repo权限；Bitbucket App Password 必须勾选Repositories: Read；GitLab Token 若用于私有实例，还需确认是否启用了allow_git_access等策略 - 临时验证命令：
curl -v -u "user:token" https://github.com/user/repo.git/info/refs?service=git-upload-pack；能列出 refs 行（如0000000000000000000000000000000000000000 refs/heads/main）才算认证通过
杀软或代理导致认证请求被拦截？绕过 TLS 校验只是临时手段
某些 Windows 杀软（如 Windows Defender）或企业代理会重写 HTTPS 流量，导致 Composer 发出的 Authorization 头被剥离或篡改，现象是 curl -v 能通但 composer install 报 401。此时禁用实时防护或换 Git Bash 运行更可靠，而非强行关 SSL 校验。
- 不要长期设
composer config --global secure-http false或cafile /dev/null，这会让所有包下载裸奔，存在中间人攻击风险 - Windows 下若用 WSL，注意
auth.json路径是 Windows 的%APPDATA%，不是 WSL 里的~/.composer；WSL 用户需手动复制或 symlink - 宝塔、AMH 等面板环境，CLI 用户（如
www）和 Web 用户权限分离，auth.json必须由实际执行composer install的用户拥有，且权限为600（chmod 600 ~/.composer/auth.json）
最常被忽略的是：私有 Git 服务（如旧版 GitLab CE）默认关闭匿名 info/refs 接口，即使 token 正确，也会因接口不可用而返回 403——这不是认证问题，是服务端配置问题，得去后台开权限。
