根本原因是目录属主为root而非当前用户，需用ls -ld定位vendor/、composer.lock或缓存目录归属，再以sudo chown -R $USER:$USER精准修复所有权，禁用sudo composer install和chmod 777。
别用 sudo composer，这是绝大多数权限问题的起点。 真正要修的是目录归属权（chown），不是反复提权运行命令。
报错路径就是修复入口
终端里那行带完整路径的错误，直接告诉你该动哪个目录。比如：
-
file_put_contents(/home/alex/myapp/vendor/autoload.php): Permission denied→ 锁定vendor/ -
Could not write to /var/www/myapp/composer.lock→ 锁定composer.lock -
Writing cache file ~/.composer/cache/repo/https---packagist.org/→ 锁定$(composer config --global cache-dir)
立刻查这三处归属：
ls -ld vendor/ composer.lock $(composer config --global cache-dir)
只要任意一行第一列显示 root（如 drwxr-xr-x 12 root root），就确认是所有权问题，不是权限位不够。
chown 归还控制权，不是 chmod 放宽权限
chmod -R 777 是毒药，会破坏 vendor/bin/ 下可执行文件的语义，CI 工具可能直接拒收；Git 提交时还会提示 ownership changed。真正该做的是归还所有权：
- 修复项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都被 root 占了？直接重置：sudo chown -R $USER:$USER ~/.composer
sudo 这里只是临时借权跑 chown，不是让你去跑 sudo composer install——后者才是污染源头。
global require 失败？先看 COMPOSER_HOME 归属
composer global require 不是“装给所有人”，只对当前 COMPOSER_HOME 对应的用户生效。如果输出是 /root/.composer 或 /var/www/.composer，说明环境已被污染：
- 查真实路径：
composer config --global home - 确认该路径属主是不是你当前执行命令的用户（
whoami） - 若属主是
root，直接sudo chown -R $USER:$USER该路径 - 插件干扰？加
--no-plugins --no-interaction快速验证
Docker 或 CI 中更隐蔽：宿主机 UID 是 1000，容器却以 UID 0 运行，挂载卷时得显式指定 user:1000 或在 Dockerfile 里加 USER 1001。
最常被忽略的点：一次 sudo composer 可能让 vendor/ 下混进 root 所有子目录，后续 composer update 可能只失败一半，chown -R 都救不回来，只能删掉 vendor/ 重来。
