Composer报Permission denied主因是sudo污染导致目录属主为root，修复应chown归还所有权而非chmod；重点检查vendor/、composer.lock、~/.composer/cache/三处权限，预防须禁用sudo composer命令。
直接说结论：Composer 报 Permission denied，90% 是因为某个目录（vendor/、composer.lock 或 ~/.composer）被 sudo 污染过，属主变成了 root，而你现在用普通用户运行，自然没权限写。修复不是调 chmod，而是把所有权还回来。
查清楚到底哪个目录没权限
别猜，先看报错里具体路径——终端输出通常会带完整文件名，比如：file_put_contents(/home/user/project/vendor/autoload.php): Failed to open stream: Permission denied，说明问题出在 vendor/；如果是 Writing cache file ~/.composer/cache/repo/https---packagist.org/provider-laravel~framework.json 失败，那就是 ~/.composer/cache/ 有问题。
快速定位三处关键位置：
-
ls -ld vendor/—— 看vendor/属主是不是你 -
ls -ld composer.lock—— 这个文件常被设成只读且属root -
ls -ld ~/.composer/cache/—— 全局缓存，最容易被sudo composer锁死
重点关注输出第一列（如 drwxr-xr-x 12 root root），只要属主不是你当前用户名（$(whoami)），就是根源。
用 chown 归还所有权，别乱 chmod
权限问题本质是“谁拥有它”，不是“它允许谁访问”。chmod 777 是临时止痛药，还会埋下 CI/CD 失败、部署报错、Git 忽略混乱等隐患。
正确操作顺序：
- 修复项目内：
sudo chown -R $USER:$USER vendor/ composer.lock
- 修复全局缓存：
sudo chown -R $USER:$USER ~/.composer/cache/
- 如果
~/.composer整个目录都属root：sudo chown -R $USER:$USER ~/.composer
注意：sudo 在这里只是提权执行 chown，不是让你用 sudo composer——后者才是罪魁祸首。
预防下次再出问题
很多团队反复踩坑，是因为第一次初始化就用了 sudo composer create-project，或者 CI 脚本默认以 root 用户跑。这些习惯必须改掉：
- 永远不用
sudo composer install、sudo composer update、sudo composer global require - 重装 Composer 时走官方流程：
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" php composer-setup.php --filename=composer --install-dir=$HOME/bin rm composer-setup.php，确保全程无sudo - Docker 中加
USER $(id -u):$(id -g)，避免容器内 UID 不匹配导致vendor/子目录混杂属主 - 如果已经混进
root所有子目录（比如vendor/symfony/console/属root，但上层vendor/属你），chown -R可能失效——直接删掉vendor/再composer install更省事
最麻烦的不是修一次权限，而是某次 sudo composer 后，vendor/ 下出现嵌套的 root 和普通用户混杂的所有权，这种状态 chown -R 都救不回来，只能删了重来。所以“别让 root 碰 vendor 和 ~/.composer”不是建议，是铁律。
