私有仓库403错误几乎都来自认证失败或URL不匹配：需检查auth.json路径及格式是否正确（GitHub用github.com、Bitbucket用bitbucket.org作key，填PAT或App Password而非密码），确认vcs类型URL以.git结尾，composer类型URL末尾带/，并用curl -v验证真实响应。
私有仓库403错误几乎都来自认证失败或URL不匹配
报 403 Forbidden 时，Composer 已成功连上服务器，但被明确拒绝访问——不是网络不通，也不是镜像失效，而是凭证错、权限缺、URL 格式不对，或者服务端根本没认出你是谁。
检查 auth.json 是否写对且位置正确
Composer 只从固定路径读取认证信息，写错位置或字段名就等于没配：
-
auth.json必须放在项目根目录（与composer.json同级）或全局配置目录（~/.composer/auth.jsonLinux/macOS，%APPDATA%\Composer\auth.jsonWindows） - Bitbucket/GitHub 私有源必须用
"http-basic"结构，不能只填"consumer-key"或"token" - GitHub 需用
github.com作 key，Bitbucket 必须用bitbucket.org，大小写和域名后缀都不能错 - 密码字段填的是 App Password（Bitbucket）或 Personal Access Token（GitHub），不是账号密码
验证仓库 URL 是否满足 type 约束
不同 type 对 URL 有硬性要求，错一条就直接 403：
-
"type": "vcs"：URL 必须是 Git 地址，以.git结尾，例如https://bitbucket.org/user/repo.git；写成https://bitbucket.org/user/repo就会触发 API 认证跳转，返回 403 -
"type": "composer"：URL 必须可访问且返回合法packages.json，末尾必须带/，否则拼成/packages.json路径错误，服务端可能拒接并返回 403（而非 404） - GitLab 私有实例若启用了 OAuth2 或 SSO，需确认 Composer 请求是否被重定向到登录页——这种重定向常被识别为“未授权”，返回 403
用 curl 模拟 Composer 请求验证真实响应
别信 Composer 报错内容，它不暴露 HTTP 状态码和响应头。直接用底层命令看服务端到底返回了什么：
- 对
vcs类型：运行curl -v -u "username:app-password" https://bitbucket.org/user/repo.git/info/refs?service=git-upload-pack，能列出 refs 才算通 - 对
composer类型：运行curl -I -u "username:token" https://your-private-repo.com/packages.json，确认返回HTTP/2 200且Content-Type是application/json - 如果返回
401 Unauthorized，说明凭证无效；返回403但curl -v显示重定向到登录页，说明服务端需要 Web Session，而 Composer 不支持
最常被忽略的一点：某些私有 Git 服务（如旧版 GitLab CE）默认关闭匿名 info/refs 接口，即使配了 token，也得在仓库设置里手动开启 “Allow requests to the repository over HTTP” 或类似选项——否则所有 vcs 拉取都会卡在 403。
