90%的“Permission denied”是目录或文件属主非当前用户所致，需定位报错路径→查ls -ld归属→用sudo chown -R $USER:$USER修复，禁用chmod 777和sudo composer install。
Composer install 从不主动“分配”用户权限——它只按当前执行用户的身份写文件；报 Permission denied 就说明目标路径不属于你，而不是权限数字不够。
为什么 composer install 报 Permission denied？
错误本质是所有权错配，不是 chmod 数字太小。常见触发点：
-
vendor/目录或composer.lock被sudo composer create-project创建过，属主是root -
COMPOSER_HOME指向了/root/.composer，导致缓存、全局 bin 都落在 root 权限路径下 - 项目目录本身（如
./）被chown -R root:root过，或挂载自容器时 uid 不匹配
典型错误信息里带的路径就是线索：file_put_contents(/var/www/myapp/vendor/autoload.php): failed to open stream: Permission denied → 查 vendor/；Writing cache file ~/.composer/cache/repo/https---packagist.org/packages.json: failed to open stream → 查 $(composer config --global cache-dir)。
修复动作必须用 chown -R $USER:$USER，不是 chmod -R 777
chmod -R 777 是危险且无效的：它不能解决属主不是当前用户的问题，还会让 CI 拒绝推送、Git 报 ownership changed、安全扫描器告警。
最小必要操作：
- 查属主：
ls -ld vendor/ composer.lock $(composer config --global cache-dir)—— 任一输出第一列不是$USER $USER，就确认是所有权问题 - 修复项目内路径：
sudo chown -R $USER:$USER vendor/ composer.lock - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 若
COMPOSER_HOME错配，先重设：export COMPOSER_HOME="$HOME/.composer"，再重跑composer config --global cache-dir确认路径已切换
为什么绝对不要 sudo composer install
它会让 vendor/ 下混入 root 所有文件，后续 composer update 可能只写一半、卡在中间，甚至 autoload.php 生成失败但不报错。这种嵌套污染，chown -R 都不一定能彻底清理干净，最后往往得删掉 vendor/ 重来。
更隐蔽的后果：
-
sudo composer global require把二进制装进/root/.composer/vendor/bin/，普通用户 shell 根本找不到命令 -
COMPOSER_HOME被悄悄覆盖成/root/.composer，之后所有全局配置都写错位置 - Web 服务器（如 PHP-FPM）以
www-data运行，根本读不到你个人账户下的缓存或插件
微服务或容器场景下，权限问题实际是构建阶段控制
Composer 不管理容器权限，它只管 PHP 包安装与加载。“给容器分配依赖权限”是概念混淆。真正要做的只有三件事：
- 严格区分
require和require-dev：运行时必需包放require，测试/静态分析工具进require-dev - 生产镜像构建必须用：
composer install --no-dev -o，否则会把几十个 dev-only 包打进线上容器 - 私有包访问靠
repositories+auth.json控制，凭证应挂载进构建容器的$COMPOSER_HOME/auth.json，而非靠容器运行时“授权”
最常被忽略的一点：umask 设置不合理（比如是 077）会导致新生成文件默认无组/其他用户读写权限，在多用户协作或 Web 服务读取时直接失败。部署前加一句 umask 002 很有必要。
