根本原因是目录权限归属错误：vendor/被root创建后普通用户无权修改，应删除vendor和composer.lock后用当前用户重装；全局bin目录不可写时应改用~/.local/bin并加入PATH；WSL/Docker需避免跨系统挂载导致权限冲突；可用strace定位真实失败路径。
Composer 安装或更新时提示 Permission denied，根本原因不是 Composer 本身权限问题，而是它试图往当前用户无写权限的目录（比如系统级 /usr/local/bin 或项目内 vendor/）写文件。
为什么 vendor 目录报 Permission denied？
常见于用 sudo composer install 初始化过项目，导致 vendor/ 所有者变成 root；后续普通用户执行 composer update 就会因无权修改 root 创建的文件而失败。
- 检查归属：
ls -ld vendor，若显示root而非当前用户名，就是这个原因 - 别直接
sudo chown -R $USER:$USER vendor—— 如果vendor/下有符号链接（如软链到全局 bin），会破坏结构 - 安全做法是删掉整个
vendor/和composer.lock，再用当前用户重装：rm -rf vendor composer.lock && composer install
全局 bin 目录（如 /usr/local/bin）写入失败怎么办？
执行 composer global require laravel/installer 时卡在 symlink 步骤，错误类似：Could not symlink ... Permission denied，说明 Composer 默认全局 bin 路径不可写。
- 查当前全局 bin 路径：
composer config --global bin-dir（默认常为/usr/local/bin） - 不建议改系统目录权限；应改用用户级路径：
composer config --global bin-dir ~/.local/bin - 确保
~/.local/bin已加入$PATH（检查echo $PATH，未包含则在~/.bashrc或~/.zshrc中加export PATH="$HOME/.local/bin:$PATH"） - 之后所有
composer global require都会软链到这里，无需 sudo
Windows WSL 或 Docker 中的权限错乱
在 WSL 里挂载 Windows 文件系统（如 /mnt/c/...），或 Docker volume 绑定宿主机目录时，Linux 权限模型和 Windows ACL 冲突，vendor/ 可能变成只读或 UID 不匹配。
- 避免在
/mnt/下运行composer install；把项目移到 WSL 原生路径（如~/projects/） - Docker 中不要用
bind mount挂整个项目进容器跑composer install；应在容器内初始化（即Dockerfile里 COPYcomposer.json后 RUNcomposer install） - 若必须宿主机执行，确认 WSL 的
/etc/wsl.conf里设置了metadata=true，否则 chmod/chown 不生效
最易被忽略的是：错误信息里出现的路径未必是你要修的地方——Permission denied 往往是上游某个临时目录（如 ~/.composer/cache/）或 opcache 写缓存失败引发的连锁反应。先用 strace -e trace=mkdir,open,write,chmod composer install 2>&1 | grep -E '(denied|fail)' 定位真实失败点，比盲目 chown 更可靠。
