90%的“Permission denied”是属主非当前用户所致，需定位报错路径→查ls -ld归属→用sudo chown -R $USER:$USER修复，禁用chmod 777和sudo composer install。
composer install 不需要 sudo，加了反而坏事儿。真正要配的不是“命令权限”，而是当前用户对项目目录、缓存路径和 vendor 生成环节的归属与默认权限控制。
为什么不能用 sudo composer install
用了 sudo，vendor/、composer.lock、甚至 ~/.composer/cache/ 全部变成 root 所有。后续你用普通用户跑 composer update 或 PHP-FPM 加载类时，会直接报 Permission denied 或 Class not found —— 因为 Web 服务器进程根本读不了 root 写的文件。
- 修复成本高：得反复跑
sudo chown -R $USER:$USER .，还容易漏掉子目录 - CI/CD 中更危险：非 root 用户执行失败，错误日志里可能只显示“failed to write”，不提权限
- 容器里雪上加霜：sudo 在容器中常被禁用，或导致 UID/GID 错乱，宿主机挂载后文件属主变成数字 ID
正确配用户权限的三步落地操作
核心逻辑是：让 composer install 生成的文件从第一行字节起，就属于你、可读写、且符合运行环境要求。
- 确认当前用户对项目根目录有完整控制权：
ls -ld .看输出是否含$USER:$USER；如果不是，先跑sudo chown -R $USER:$USER . - 设好
umask：在运行composer install前执行umask 002（开发/组协作）或umask 022（生产），它决定新文件默认权限（775/664 或 755/644） - 检查
COMPOSER_HOME是否指向安全路径：运行echo $COMPOSER_HOME，若为空或指向/root/.composer，立即设export COMPOSER_HOME="$HOME/.composer"并写入~/.bashrc
Docker 和 CI 环境下必须额外注意的点
本地权限配对了，不等于容器或流水线里也 OK。常见断裂点在 UID/GID 不一致和 volume 挂载时机。
- 构建镜像时，别在运行容器里
composer install：改用多阶段构建，在 builder 阶段装依赖，再用COPY --chown=www-data:www-data --from=builder /app/vendor /app/vendor复制 - 本地开发用 docker run，加上
-u $(id -u):$(id -g)参数，确保容器内进程 UID 和宿主机一致 - 绝对不要在已挂载的 volume 目录里执行
composer install：比如-v $(pwd):/app后进容器跑 install，生成的vendor/文件在宿主机上 UID 常是 1001、1002 这类随机数，你无法直接chown
最易被忽略的是 umask 的作用域——它只影响当前 shell 会话，新开终端或 CI 脚本里不会继承。每次部署脚本开头加一行 umask 002，比事后 chmod -R 更轻量、更可靠。
