auth.json 权限问题的本质，不是配置文件写错了，而是文件或父目录的归属权不在你手里。最常见的报错“Failed to open stream: Permission denied”，背后往往是 `~/.composer/auth.json` 或项目根目录下的该文件，其属主是 `root` 或其他用户，你当前的操作账户根本没权限去动它。
很多人一看到 Composer 报“权限不足”，第一反应就是 `sudo` 加上各种 `chmod 777`。但在这个场景下，这完全是走错了方向。`auth.json` 的问题，几乎从不源于文件内容格式，而始终卡在“归属错位”这个点上。一旦父目录或文件本身被 `root` 占了，哪怕你 `chmod 777` 也救不回写权限——Linux 内核不允许非属主进程往非属主文件里写内容，这是硬限制，Composer 也绕不过去。
auth.json 所在路径归属不对就写不进去
Composer 在读写认证凭据时（比如执行 composer config --auth http-basic packagist.org user pass），会尝试修改 auth.json。如果这个文件或其所在目录的 owner 不是你当前的操作用户，那系统就会直接拒绝，报出 Permission denied。那么，怎么排查是哪个文件出了问题？
- 查项目级
auth.json：在项目根目录下运行ls -ld auth.json，看第三列（属主）是不是$(whoami)。 - 查全局级
auth.json：先用composer config --global home确认全局配置目录的位置，再运行ls -ld $(composer config --global home)/auth.json检查归属。 - 特别留意两种错误路径：
/root/.composer/auth.json（说明之前误用了sudo composer config，把全局配置写到了 root 家目录下）和/var/www/.composer/auth.json（常见于 CI 或 PHP-FPM 用户环境）。
别改 chmod，直接 chown 归还控制权
记住一句话：chmod 600 auth.json 对归属权的问题毫无意义，只要文件属主不是你，连打开都失败。真正要动的是文件的所有权，也就是 chown。
- 修复项目级：
sudo chown $(whoami):$(whoami) auth.json - 修复全局级：
sudo chown -R $(whoami):$(whoami) $(composer config --global home) - 如果
auth.json不存在但目录不可写：记得也要修父目录：sudo chown $(whoami):$(whoami) $(dirname $(composer config --global home))
auth.json 被写入失败时的典型报错特征
注意区分是“读取失败”还是“写入失败”，这能帮你快速定位问题方向：
- 写入失败（最常见）：报错信息里通常会有
file_put_contents(/home/user/.composer/auth.json): Failed to open stream: Permission denied。这就是典型的文件属主不对，写不进去。 - 读取失败（较少见）：报错类似
Could not parse authentication file /home/user/.composer/auth.json: failed to open stream。先别急着怀疑 JSON 格式，同样先查ls -ld看文件属主——很多时候根本到不了解析那一步，文件就打不开。 - 一个非常重要的线索：如果报错里出现了
/root/.composer/auth.json，说明你之前用sudo composer config --global干过什么。这时候最干脆的做法是：rm -f /root/.composer/auth.json，然后切回普通用户重新执行命令。
一句话总结：auth.json 的权限问题，十有八九是“你是谁”和“文件属于谁”不匹配导致的。别跟 chmod 较劲，直接 chown 才是正解。
