auth.json必须与repositories配置严格匹配且路径、权限、结构合规,否则composer直接忽略;它仅在项目根目录、composer_home(如~/.composer/auth.json)、系统级目录按优先级查找,权限需为600,域名key须精确匹配请求host,不支持协议或路径。

auth.json 不是“配了就能用”,它必须和 repositories 配置对得上,且路径、权限、结构全要合规,否则 Composer 直接无视。
auth.json 放哪才被读取?
Composer 只在三个位置找 auth.json,按优先级从高到低:
- 当前项目根目录(和
composer.json同级),权限必须是600(Linux/macOS)或至少不公开可读;放错目录(比如vendor/或config/)就等于没写 -
COMPOSER_HOME目录下(通常是~/.composer/auth.json),适合全局凭证,但会被项目级覆盖 - 系统级配置目录(极少用,不推荐)
常见错误:把 auth.json 提交进 Git、放在 .gitignore 里却忘了本地开发时需要它、或者 chmod 755 导致 Composer 主动跳过读取(安全机制)。
http-basic 凭证怎么写才生效?
关键不是“写对用户名密码”,而是 key 必须精确匹配仓库的**域名**,且不能带协议或路径:
- 如果你的私有 Packagist 地址是
https://repo.company.com,key 就得是"repo.company.com",不是"https://repo.company.com",也不是"repo.company.com/api/v1" - GitHub 私仓用
github-oauth,但 key 固定为"github.com",哪怕你用的是 GitHub Enterprise,也得这么写,再额外配gitHubUrl到config - 密码必须是明文字符串,
"${GITHUB_TOKEN}"这类环境变量引用在auth.json里完全不解析
示例(私有 Packagist):
{
"http-basic": {
"repo.company.com": {
"username": "api-token",
"password": "abc123def456"
}
}
}
为什么填了 auth.json 还报 401?
大概率不是凭证错了,而是流量根本没走到你的私有域名:
- 检查
composer.json的repositories是否显式声明了该源,且type是"composer"(不是"vcs") - 确认没启用镜像源(如阿里云镜像)并禁用了
packagist.org,否则 Composer 会绕过你的私有域名直连镜像,自然用不上auth.json里的凭证 - 运行
composer install -vvv,看日志里实际请求的 URL 是不是你的私有域名;如果显示https://mirrors.aliyun.com/...,说明配置没生效 - vcs 类型仓库(如
"type": "vcs", "url": "git@gitlab.company.com:group/repo.git")不走http-basic认证,它走 SSH 或 git credential,auth.json对它无效
CI/CD 中怎么安全传凭证?
别把 auth.json 提交进代码库,也不要在 CI 脚本里硬编码密码:
- GitLab CI 推荐用
$CI_JOB_TOKEN+ 动态生成auth.json:echo '{"http-basic":{"gitlab.company.com":{"username":"gitlab-ci-token","password":"'$CI_JOB_TOKEN'"}}}' > auth.json - GitHub Actions 推荐用 SSH 部署密钥:注入
DEPLOY_KEYsecret,用ssh-agent加载,然后让仓库 URL 写成git@开头,彻底绕过auth.json - 全局配置(
composer config --global http-basic...)在 CI 中容易污染缓存,建议每次构建都重写auth.json并限定作用域
最易被忽略的一点:多个私有仓库共存时,auth.json 里每个域名必须独立配置,不能合并或复用 key;而 repositories 数组里同名包只认第一个源,认证失败不会 fallback 到第二个。











