composer报错“Permission denied”是因当前用户对vendor/或项目目录无写权限，常见于sudo创建项目、文件复制保留root权限、误用chown或umask过严；应确认用户组后执行sudo chown -R $USER:$GROUPS .修复。
Composer 报错 failed to open stream: Permission denied，基本就是当前用户对目标目录（通常是 vendor/ 或 composer.json 所在目录）没有写权限，不是 Composer 本身坏了。
为什么 composer install 或 composer update 突然报权限错误？
常见于以下几种情况：
- 项目目录是用
sudo composer create-project创建的，导致vendor/所有者变成root，后续普通用户执行命令时无法覆盖 - 项目从其他机器或 docker 容器复制过来，文件保留了原始 UID/GID，与当前系统用户不匹配
- 使用了
chown -R root:root .之类的误操作，把整个项目设成了只读 - 某些 linux 发行版（如 ubuntu）默认启用
umask 022，但若环境里被改成027或更严格，新建目录可能不带组/其他用户写权限
快速检查并修复目录权限
先确认出问题的路径 —— 错误信息里一般会带具体文件，比如：failed to open stream: Permission denied in /path/to/project/vendor/autoload.php。重点看 vendor/ 和项目根目录。
- 运行
ls -ld . vendor/，检查所有者和权限位；如果显示drwxr-xr-x 1 root root，就说明不是当前用户所有 - 用
whoami和id -gn确认当前用户名和主组名 - 修复命令（假设当前用户是
alice，组是alice）：sudo chown -R alice:alice .注意：只对当前目录及其子目录生效，不要加
/结尾避免误改系统路径 - 如果只想修 vendor 目录（更安全）：
sudo chown -R alice:alice vendor/
避免下次再踩坑的实操习惯
Composer 本身不推荐加 sudo 运行，一旦用了，几乎必然引发权限混乱。
- 永远用普通用户执行
composer install、composer update、composer require - 如果提示
Could not write to /home/alice/.composer/cache，说明全局缓存目录权限也错了，修复：sudo chown -R alice:alice ~/.composer - CI/CD 或 Docker 场景下，确保构建用户 UID 与宿主机一致，或在 Dockerfile 中显式指定
USER 1001（对应你的本地 UID） - mac 用户注意：通过 Homebrew 安装的 Composer，若曾用
brew install --user，也可能因~/.composer权限锁死，同样适用chown修复
最麻烦的情况不是权限没设对，而是你改完一次后，又不小心在某个子 shell 或 ide 终端里用了 sudo composer —— 它会悄悄把新生成的文件切回 root，前功尽弃。盯住 ls -l vendor/ 的输出，比什么都管用。