auth.json 应放在 composer_home 目录（如 ~/.composer/auth.json），不可与 composer.json 同放项目根目录；因前者含敏感凭据属用户级配置，后者为共享的项目级配置，混放易导致凭据泄露。
auth.json 该放哪，为什么不能和 composer.json 放一起
敏感 token（比如私有包仓库的 http-basic 凭据、GitHub github-oauth token）绝不能写进 composer.json，更不能提交到 Git。因为 composer.json 是项目级配置，天然要共享；而认证信息是环境/用户级的，必须隔离。
Composer 默认从 auth.json 读取凭据，且会按顺序查找以下位置：
- 当前项目根目录下的
auth.json（❌ 最危险，容易误提交） -
COMPOSER_HOME目录下的auth.json（✅ 推荐，通常是~/.composer/auth.json或%APPDATA%\Composer\auth.json）
所以第一步就是：删掉项目里的 auth.json，把内容移到全局位置，并确保该文件权限为 600（Linux/macOS）或等效限制（Windows 下需禁用继承权限）。
用 composer config 命令安全写入 token
手动编辑 auth.json 容易出格式错误或权限遗漏，直接用 Composer 自带命令最稳妥。它会自动写入 COMPOSER_HOME 下的 auth.json，并设好基础权限。
常见场景示例：
- 为私有 GitLab 仓库配 HTTP Basic 认证：
composer config -g http-basic.gitlab.example.com username token123 - 为 GitHub 设置 OAuth token（用于访问 private repo 或提高 API 限流）：
composer config -g github-oauth.github.com abcdef0123456789...
注意：-g 表示全局配置，不加就是项目级（又回到风险区）。执行后可检查 cat $(composer config -g home)/auth.json 确认内容，但别在终端历史里留明文 token —— 命令本身不回显 token，这点很关键。
CI/CD 环境下怎么安全传入 auth.json
CI 流水线（如 GitHub Actions、GitLab CI）没法交互输入，也不能把 auth.json 文件硬塞进仓库。正确做法是：运行时动态生成，且生命周期仅限当前 job。
- GitHub Actions 中，用
echo+env注入（token 存在 Secret 中）：echo '{"http-basic": {"myrepo.example.com": {"username": "ci", "password": "${{ secrets.PRIVATE_REPO_TOKEN }}"}}}' > ~/.composer/auth.json - GitLab CI 中类似，但注意路径可能为
$HOME/.composer/auth.json，且需提前mkdir -p $HOME/.composer - 绝对不要用
cp复制本地auth.json，也别用base64编码后解码 —— 这些都会在日志或缓存中留下痕迹
验证是否生效：在 CI 脚本里加一句 composer config -g --list | grep -i auth，能看到已设置项即可，不用输出完整文件。
为什么 vendor/bin/composer install 有时还是报 401
不是 token 错，而是 Composer 没找到它 —— 最常见三个原因：
- 用了
sudo composer install：sudo切换用户后，COMPOSER_HOME变成 root 的路径，而你的 token 在普通用户家目录下 - 容器或 Dockerfile 中没挂载
~/.composer，或者COMPOSER_HOME被覆盖成别的路径（比如/tmp/composer） - 私有仓库域名拼写不一致：比如
config -g http-basic.repo.example.com写了repo.example.com，但composer.json里仓库 URL 是https://api.repo.example.com—— 域名必须完全匹配
查问题最快方式：composer config -g --list 看全局配置有没有；再用 composer diagnose 检查 auth 配置是否被识别；最后确认网络请求发往的 host 是否和 auth.json 里 key 完全一致。
