composer报错failed to create directory或permission denied，本质是当前用户对vendor/、~/.composer/等目录无写权限，禁用sudo运行；应修复属主为当前用户（如chown -r $user:$user vendor/和~/.composer/），并避免chmod 777。
Composer 报错 Failed to create directory 或 Permission denied，本质是当前用户对目标目录（如 vendor/、~/.composer/ 或项目根目录）没有写权限，不是 Composer 本身的问题，也不该靠 sudo composer install 硬扛。
为什么不能用 sudo 运行 composer
用 sudo composer install 会以 root 身份创建 vendor/ 和缓存文件，导致后续普通用户无法修改或删除这些文件，下次再运行 composer update 就会卡在权限错误上——这是最典型的“越修越错”操作。
-
vendor/下所有文件属主变成root，普通用户无权写入或清理 -
~/.composer/cache/目录被 root 创建后，普通用户无法命中缓存，每次重下包 - CI/CD 或 Web 服务器（如 nginx + php-fpm）通常以非 root 用户运行，根本读不了 root 写的
vendor/
修复 vendor 目录属主和权限
先确认当前项目路径，再把 vendor/ 及其内容的所有权还给当前用户（比如你的登录用户名是 alice）：
chown -R alice:alice vendor/
如果 vendor/ 不存在，但报错发生在创建阶段，说明上层目录（如项目根目录）不可写。检查并修复父目录权限：
- 运行
ls -ld .查看当前目录权限，确保有drwxr-xr-x或更宽松，且属主是你自己 - 若属主是 root，执行
sudo chown -R $USER:$USER .（注意末尾的.表示当前目录） - 避免直接
chmod 777——开放写权限给 all group/others 是安全隐患
修复 ~/.composer 目录权限
Composer 的全局缓存、配置、插件都存在 ~/.composer/，如果这个目录被 root 占用过，也会持续报错：
ls -la ~/.composer/
如果输出中显示 owner 是 root，执行：
sudo chown -R $USER:$USER ~/.composer/
补充验证：
-
composer config --global home确认全局路径是否真为~/.composer -
composer diagnose会检查缓存目录可写性，失败项会明确提示路径 - 某些系统（如 Ubuntu WSL）可能因挂载选项限制
metadata，导致chown无效 —— 此时需改用 Windows 侧设置或换用 ext4 分区存放项目
预防：让 composer 始终以当前用户身份运行
根本解法是杜绝 root 干预。检查有没有以下情况：
- Shell 配置文件（
~/.bashrc、~/.zshrc）里 alias 了alias composer='sudo composer'—— 删除它 - 使用了第三方一键脚本或 Docker Compose 模板，内部硬编码了
sudo—— 改用普通用户启动 - Web 服务（如 Apache 的
www-data）需要访问vendor/？那就把该用户加进你的用户组，并设目录组写权限：chmod -R g+rwX vendor/ && chmod g+s vendor/
真正麻烦的从来不是命令敲不对，而是权限链断在某个你没意识到的环节——比如 ~/.composer/ 属主错了，却反复去修项目目录；或者 vendor/ 权限正常，但 composer.json 所在目录是只读挂载。查错时，优先 ls -ld 看报错路径本身的属主和权限，别跳步。
