auth.json 生效位置按优先级依次为：COMPOSER_AUTH 环境变量、项目根目录、用户主目录；GitHub 需配置 github-oauth 与含 repo 权限的 classic PAT；GitLab 等须用 http-basic 且域名严格匹配；401 错误需检查缓存、锁文件、Nginx 头透传及 Git 凭据助手。
auth.
js
on 放哪儿才生效？
Composer 只在特定位置查找
，顺序错了就白配。它按优先级从高到低依次检查：
环境变量（JSON 字符串）
当前项目根目录下的
用户主目录的
（Linux/macOS）或
（Windows）
项目级配置最安全——只影响当前项目，不会污染全局；但 CI/CD 里常靠环境变量注入，避免把令牌写进 Git。
GitHub Personal Access Token 怎么填？
GitHub 私有仓库需要的是
配置，不是用户名密码。Token 必须带
权限（如果是组织私仓，还需
）。
正确写法：
常见错误：
误填成 GitHub 账号密码（已不支持）
Token 权限不足，报错
或
用了 GitHub App token 或 fine-grained token 却没配
段（目前 Composer 原生只认 classic PAT）
GitLab 和私有 Packagist 怎么设域名和令牌？
GitLab、Bitbucket、自建 Satis/SatisPress 都走
，但必须严格匹配仓库域名。
php版微信js-sdk支付接口类
php版微信js-sdk支付接口类
下载
比如 GitLab 实例在
，且包地址是
，就得这样写：
注意点：
域名必须和
里
的 URL 主机名完全一致（
≠
）
GitLab 的 password 字段填的是 Personal Access Token，不是密码；Token 权限需含
自建 Packagist 若启用了 Basic Auth，也走同一套
，填管理后台给的账号密码即可
为什么
还是 401？
认证失败往往不是配置错，而是缓存或协议层干扰。
排查步骤：
运行
确认全局配置没覆盖项目配置
删掉
和
，再
（update 可能复用旧 lock 里的元数据）
加
参数看详细请求：如果看到
返回 401，说明 OAuth 失效；如果看到
重定向到登录页，说明
域名对不上
私有 Packagist 后端若用 Nginx，确认没误删
请求头（需显式透传：
）
最易忽略的是：Git 本身也会读
里的 credential helper，如果它缓存了错误凭据，Composer 走 HTTPS 克隆时可能被它劫持——此时要
清一下。
auth.jsonCOMPOSER_AUTHauth.json~/.composer/auth.json%APPDATA%\Composer\auth.jsongithub-oauthreporead:org
{
"github-oauth": {
"github.com": "ghp_xxx..."
}
}Could not fetch https://api.github.com/... 404401github-apphttp-basicgitlab.example.comhttps://gitlab.example.com/group/pkg.git
{
"http-basic": {
"gitlab.example.com": {
"username": "your_username",
"password": "your_personal_access_token"
}
}
}composer.jsonrepositoriesgitlab.example.comhttps://gitlab.example.comread_repositoryhttp-basiccomposer updatecomposer config --global --list | grep authvendor/composer.lockcomposer install-vGET https://api.github.com/repos/xxx/xxxGET https://gitlab.example.com/group/pkg.githttp-basicAuthorizationproxy_pass_request_headers on;~/.gitconfiggit credential reject