根本原因是 Composer 缓存或 vendor 目录被 root 等非当前用户占用，导致权限拒绝；执行 sudo chown -R $USER:$USER ~/.composer 和 ./vendor 即可修复，且切勿使用 sudo composer install。
composer install 报 failed to open stream: Permission denied 怎么办
根本原因是 Composer 缓存目录（如 ~/.composer/cache）或项目 vendor 目录被错误属主占用，常见于用 sudo composer install 后普通用户再操作时触发。系统拒绝当前用户写入，不是网络或配置问题。
确认缓存目录路径和当前属主
先查 Composer 实际使用的缓存位置：
composer config --global cache-dir
默认是 ~/.composer/cache，但可能被改过。再检查该路径归属：
ls -ld ~/.composer/cache
如果输出中 owner 不是当前登录用户（比如显示 root 或其他用户），就确认是属主问题。常见错误现象包括：
file_put_contents(/home/user/.composer/cache/repo/https---packagist.org/provider-x.json): failed to open stream: Permission deniedCould not delete /path/to/vendor/composer/xxx: Permission denied
修复属主：chown 重置 ~/.composer 及其子目录
执行以下命令一次性修正（把 yourusername 换成你自己的用户名，或直接用 $USER）：
sudo chown -R $USER:$USER ~/.composer
注意必须加 -R，否则只改目录本身，不改内部 cache、repo、downloads 等子目录。如果项目 vendor 也出现权限问题，顺手一起修：
sudo chown -R $USER:$USER ./vendor
不需要重启终端或重装 Composer，改完立刻生效。
预防下次再 sudo composer
绝大多数权限问题源于误用 sudo composer。Composer 设计就是以当前用户身份运行的，sudo 会把缓存、vendor 文件全归到 root 名下。牢记：
- 永远不要在项目里跑
sudo composer install - 全局命令如
composer global require同样不能加sudo - 如果提示 “Permission denied” 在
/usr/bin/composer，那是安装方式问题，不是缓存权限问题，需另查
真正复杂的点在于：有些 CI 环境或 Docker 容器里，UID 不一致会导致 chown $USER 失效；这时候得看容器启动时指定的 user ID，用数字 UID 替代用户名操作。
