问题根源是文件属主为root而非当前用户，需用chown修复vendor/、composer.lock及全局缓存目录归属，禁用sudo执行composer命令以防嵌套权限异常。
问题不在 composer.json 本身，而在它所在的目录、vendor/ 或 composer.lock 的属主被 root 占了
看报错末尾路径，直接锁定问题位置
Composer 报 “Permission denied” 时，错误信息末尾一定带完整路径，比如：
-
file_put_contents(/home/alex/myapp/vendor/autoload.php): Permission denied→ 问题在vendor/ -
Could not write to /home/alex/myapp/composer.lock→ 问题在composer.lock -
Writing cache file ~/.composer/cache/repo/https---packagist.org/→ 问题在全局缓存目录
别猜，就照着这个路径查归属。执行这三行命令，看输出第三列（属主）是不是你当前用户名：
ls -ld vendor/ ls -ld composer.lock ls -ld $(composer config --global cache-dir)
用 chown 归还所有权，不是 chmod 改权限位
权限拒绝的根源几乎全是“东西不归你”，不是“权限数字太小”。chmod -R 777 是危险操作，会导致 vendor/bin/phpunit 被 CI 拒收、Git 提示 ownership changed。
- 只修复
vendor/：sudo chown -R $USER:$USER vendor/ - 只修复
composer.lock：sudo chown $USER:$USER composer.lock - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都是 root 的：sudo chown -R $USER:$USER ~/.composer，再补一句chmod -R u+rw ~/.composer防 umask 导致子目录不可写
为什么不能 sudo composer update
用 sudo composer update 会以 root 身份生成部分 vendor/ 子目录，后续普通用户运行 composer install 可能只失败一半——有些文件写入成功，有些被拒，这时 chown -R 都救不回来，只能删掉 vendor/ 重来。
- 永远用普通用户执行
composer update和composer install - 如果项目目录曾被
sudo污染过，先执行：sudo chown -R $USER:$USER ./（注意结尾的./） - 检查
COMPOSER_HOME是否指向了/root/.composer或/var/www/.composer，这种配置会让所有global命令默认跑在错误用户上下文里
真正卡住人的，往往是嵌套归属异常：比如 vendor/ 属于你，但里面某个包的 bin/ 目录属 root；或者 composer.lock 是你写的，但 vendor/autoload.php 是 root 创建的。这种情况下，单靠看报错路径还不够，得进目录里 ls -l 逐层确认。
