Composer 文件权限问题根源是用户与目录归属不一致，解决关键是确保运行用户对项目目录、vendor、缓存路径拥有读写权限，禁用 sudo，正确配置 cache-dir，Docker/CI 中显式指定 UID/GID。

Composer 安装时遇到文件权限问题，通常是因为当前用户对目标目录（如 vendor、composer.json 所在目录或系统级缓存路径）没有读写权限，导致创建文件、解压包或写入锁文件失败。核心解决思路是：确保 Composer 运行用户拥有对应路径的完整控制权，而不是盲目用 sudo 或全局降权。

检查并修正项目目录权限

Composer 默认在当前目录操作，若项目目录属主不是当前用户（例如通过 sudo git clone 或从 root 用户复制而来），vendor 目录就无法写入。

• 运行 ls -ld . 查看当前目录归属，确认用户和组是否匹配当前登录用户
• 若不匹配，用 sudo chown -R $USER:$USER ./ 递归修正（Linux/macOS），Windows WSL 同理；Git Bash *意使用 Windows 权限工具或重置为 NTFS 正常继承
• 避免用 chmod 777 全开放——这有安全风险，仅需保证用户可读写即可（如 755 对目录，644 对文件）

配置 Composer 使用用户专属缓存路径

Composer 缓存默认放在 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\cache（Windows）。若该路径被其他用户或系统策略锁定，安装会卡在“Downloading”或报 failed to open stream。

• 查看当前缓存位置：composer config --global cache-dir
• 手动指定一个确定可写的路径，例如：composer config --global cache-dir "$HOME/.composer-cache"
• 再执行 mkdir -p $HOME/.composer-cache 并确认属主正确

避免在 root 或 sudo 下运行 composer install

用 sudo composer install 会导致生成的 vendor 文件全部属主为 root，后续普通用户无法修改或更新，形成恶性循环。

• 始终以普通用户身份运行 composer install 和 composer update
• 如果提示 “Permission denied” 在 vendor/，先清理：rm -rf vendor composer.lock，再确保目录权限正确后重试
• CI/CD 环境中（如 GitHub Actions、Docker），显式指定运行用户（如 user: 1001）并挂载缓存卷时设置好 UID/GID

处理 Docker 或共享目录中的特殊权限

在 Docker 容器内运行 Composer，或项目位于 VirtualBox/Vagrant 共享文件夹、NFS 卷时，文件系统可能不支持 chmod/chown，或 uid/gid 映射错乱。

• Docker 中优先使用非 root 用户构建镜像，例如在 Dockerfile 中添加 USER 1001 并确保 /var/www 目录属主为该 UID
• 宿主机共享目录下，用 docker run -u $(id -u):$(id -g) 显式传递用户身份
• 临时绕过写权限限制（仅开发环境）：可在 composer.json 中设置 "config": { "fxp-asset": { "installer-paths": { "npm-asset-library": "assets/npm" } } }，但更推荐修复底层权限

基本上就这些。权限问题本质是用户与路径的归属关系不一致，定位清楚谁在跑、往哪写、谁拥有那个地方，比查报错信息本身更快。Composer 不需要特权，它只需要“被允许做事”的环境。