根本原因是操作系统拒绝Composer向目录写文件，常见于目录属主为root而普通用户执行、Docker挂载权限不匹配或误用sudo导致vendor属主变为root。
为什么 composer install 报 “Permission denied”
根本原因不是 Composer 本身没权限，而是它试图往当前目录（比如 vendor/）写文件时，操作系统拒绝了——常见于项目目录属主是 root，而你用普通用户运行命令；或 Docker 容器里挂载的宿主机目录权限不匹配；或用了 sudo composer install 导致生成的 vendor/ 文件属主变成 root，后续普通用户就再也写不进去了。
典型错误现象：
file_put_contents(./vendor/autoload.php): failed to open stream: Permission denied-
mkdir(): Permission denied在创建vendor/或cache/时出现 - 明明有写权限，但
ls -l vendor显示属主是root
别用 sudo composer install ——这是最危险的惯性操作
它看似“能跑”，实则埋下持续性权限混乱：Composer 会以 root 身份创建整个 vendor/ 目录树，后续所有开发操作（git pull、php artisan、IDE 自动索引）都可能因权限问题中断。尤其在团队协作或 CI 环境中，这种临时 sudo 会污染环境一致性。
正确做法是让目录归属回归当前用户：
- 确认当前用户名：
whoami - 把项目目录完整归还给自己：
sudo chown -R $(whoami):$(whoami) ./（注意结尾的./，别漏掉） - 如果只修复
vendor：sudo chown -R $(whoami):$(whoami) vendor/ - Windows WSL 或 macOS 上，避免用
sudo启动终端，否则整个 shell 会继承 root 权限
Composer 全局安装路径权限问题怎么处理
全局命令 composer 本身没问题，但它的缓存和可执行脚本默认放在 ~/.composer/ 和 ~/.composer/vendor/bin/。如果这些目录被 sudo 污染过，就会导致 composer global require 失败。
检查并修复：
- 看缓存路径：
composer config --global cache-dir（通常是~/.composer/cache） - 确认归属：
ls -ld ~/.composer，如果不是当前用户，立刻修复：sudo chown -R $(whoami):$(whoami) ~/.composer - 避免未来出问题：永远不要用
sudo composer global require；如需全局工具（如laravel/installer），改用composer global require --no-plugins（跳过插件加载，减少权限敏感操作）
Docker 或 CI 环境中权限错乱的务实解法
本地好好的，一进容器就 Permission denied？本质是 UID 不一致：宿主机用户 UID 是 1001，但容器内默认用的是 0（root）或另一个 UID，导致挂载卷的文件不可写。
不依赖 sudo 的稳定方案：
- 构建镜像时指定非 root 用户：
RUN addgroup -g 1001 -f www && adduser -S phpuser -u 1001，然后USER phpuser - 运行容器时对齐 UID：
docker run -u $(id -u):$(id -g) ... - CI 脚本里加一句前置检查：
test -w . || { echo "project dir not writable"; exit 1; } - 实在要快速绕过（仅限测试）：用
docker run --privileged是错的，应该用--user $(id -u):$(id -g)
复杂点在于，有些基础镜像（比如官方 php:8-cli）默认就是 root，且不预建用户；这时候靠 chmod 777 或反复 chown 都只是掩盖问题，真正要解决得从用户映射入手。
