Composer.json写入失败主因是项目根目录无写权限，需用chown修复目录归属，而非仅改文件权限；同时排查COMPOSER_HOME路径及Web服务器用户权限问题。
composer.json 写入失败，大概率是项目根目录权限不对
Composer 需要往当前目录写 composer.json（比如执行 composer init 或 composer require 时自动更新），但失败提示 “Permission denied” —— 这通常不是 composer.json 文件本身只读，而是它所在的**项目根目录**没有写权限。
验证方法很简单：touch test.tmp && rm test.tmp。如果这一步就报错，说明当前目录不可写，composer.json 自然也写不进去。
- 检查目录归属：
ls -ld .，确认输出中 owner 是你的当前用户（如alex），而不是root - 若 owner 是
root，运行：sudo chown -R $USER:$USER /path/to/your/project - 别只改
composer.json文件权限（chmod 644 composer.json没用），它依赖父目录可写才能创建/重命名/覆盖 - 在 WSL 或 Docker 中挂载了
/mnt/c/或/var/www路径时，Linux 权限模型可能失效，chown成功但实际无效
误用 sudo 后，composer.json 所在目录变成 root-owned
很多人第一次跑 sudo composer init，结果整个项目目录（包括 .、composer.json、vendor/）都被设为 root 所有。之后再用普通用户执行任何命令，连 ls -l 都可能卡住，更别说写入。
这不是 Composer 的 bug，是 Linux 文件系统权限的自然表现：普通用户不能往 root-owned 目录里写文件。
- 先确认当前用户：
whoami - 查项目根目录归属：
ls -ld . - 若 owner 是
root，必须修复整个路径：sudo chown -R $USER:$USER .（注意结尾的.） - 修复后立即测试：
composer require monolog/monolog --dry-run，避免二次污染
COMPOSER_HOME 环境变量指向错误路径，导致配置写不进 composer.json
当你执行 composer config --editor 或某些插件尝试修改 composer.json 时，如果报错或静默失败，可能是 Composer 实际操作的是另一个 composer.json —— 因为 COMPOSER_HOME 或 COMPOSER 环境变量被设偏了。
例如，在 CI 环境中 COMPOSER=/tmp/composer.json，但该路径不可写；或 Windows Git Bash 下 COMPOSER_HOME 指向空目录，导致配置被丢弃。
- 查当前生效路径：
echo $COMPOSER_HOME（Linux/macOS）或echo %COMPOSER_HOME%（Windows） - 确认该路径下是否存在
config.json，且ls -ld显示可写 - 临时绕过环境变量测试：
COMPOSER= ./composer.json composer config --editor - 不要手动编辑
composer.json来“修复”，所有变更应通过composer config或composer require触发
Web 服务器用户与 CLI 用户不一致，间接影响 composer.json 更新
在 Laravel、Symfony 等框架中，有时会通过 Web 接口触发 composer require（比如后台包管理），此时实际执行用户是 www-data 或 nginx，而非你的终端用户。它对项目目录没写权限，自然无法更新 composer.json。
这类问题不会在终端报错，但 Web 请求会静默失败或返回 500，日志里常看到 “failed to open stream: Permission denied”。
- 检查 Web 服务运行用户：
ps aux | grep -E '(apache|httpd|nginx|php-fpm)' - 把该用户加入你的用户组：
sudo usermod -a -G $USER www-data - 设项目目录组可写：
sudo chgrp -R $USER . && chmod -R g+w . -
vendor/和storage/可单独处理，但composer.json必须确保 CLI 和 Web 用户都能写（或统一用 CLI 管理，禁用 Web 端动态安装）
真正麻烦的不是某一个目录权限错，而是多个路径（项目根目录、~/.composer、缓存目录、COMPOSER_HOME）归属不一致，又混着用了 sudo 和普通用户命令。修完一个，另一个又冒出来——所以动手前，先用 ls -ld 把所有可疑路径扫一遍，比反复试错快得多。
