composer install 报错“failed to open stream: Permission denied”是因目录写入权限不足，常见于linux/macos下sudo误用导致vendor属主为root，或windows中onedrive等同步软件锁定文件，应避免sudo、检查目录归属与父目录权限、调整umask、修复~/.composer归属，并在docker中指定UID运行。
Composer install 报错 failed to open stream: Permission denied
这是典型的目录写入权限不足，不是 Composer 本身坏了，而是它想往 vendor/ 或 composer.json 同级目录写文件时被系统拦下了。Linux/macOS 常见于用 sudo composer install 初始化过项目后，普通用户再执行就卡住；Windows 则多因杀毒软件或 OneDrive 同步锁住了文件。
- 别用
sudo composer install（除非你明确知道后果）——这会让vendor/下所有文件属主变成 root，后续普通用户无法修改或更新 - 检查当前目录归属：
ls -ld . vendor/，如果vendor/显示属主是root，直接删掉重来更省事 - Windows 用户重点看
composer.json所在路径是否在 OneDrive、腾讯微云、360保险箱等实时同步/保护目录里，临时退出同步再试
vendor 目录权限修复命令不生效？检查 umask 和父目录权限
单纯 chmod -R u+rw vendor/ 经常无效，因为新生成的文件受系统 umask 控制，且父目录（如项目根目录）若无写权限，子目录 chmod 也白搭。
- 先确认父目录可写：
touch ./test-perm && rm ./test-perm，失败说明根目录权限不对，用chmod u+w .修复 - 查看当前 umask：
umask，如果是0022，新建文件默认权限就是644（无写权），Composer 某些脚本需要写入缓存或生成 autoload 文件，就会失败 - 临时放宽 umask：
umask 0002再跑composer install，比硬改每个文件权限靠谱
非 root 用户如何安全使用 Composer 全局命令（如 create-project）
全局命令报同样错误，往往是因为 ~/.composer/ 目录权限混乱，或者 Composer 自身缓存目录被锁死。
- 检查
~/.composer/归属：ls -ld ~/.composer，如果不是当前用户，运行sudo chown -R $USER:$USER ~/.composer - 清空缓存再试：
composer clear-cache，避免旧缓存文件权限残留干扰 - 不建议把
~/.composer/vendor/bin加进 PATH 后用全局二进制——改用php /path/to/composer.phar更可控，尤其在 CI 或多人共用服务器时
Docker 环境下 Composer 权限错误：容器内 UID 不匹配宿主机
本地开发用 Docker 运行 composer install，生成的 vendor/ 在宿主机上变成 root 所有，下次 host 端 ide 或 git 操作就报权限错。
- 启动容器时指定 UID：
docker run -u $(id -u):$(id -g) -v $(pwd):/app php:8.2-cli composer install - 或在
Dockerfile中提前建好非 root 用户，并确保WORKDIR对该用户可写 - 别依赖
chown -R宿主机修复——Docker for Mac/Windows 的文件挂载机制会让这类操作极慢甚至失败
事情说清了就结束。最常被忽略的是：权限问题从来不是 Composer 的 bug，而是环境所有权和执行上下文没对齐。修之前，先 ls -l 看一眼谁在挡路。