Permission denied 根源是文件所有权错误而非权限不足，应优先用 chown 修复 owner，如 sudo chown -R $USER:$USER vendor/ 和 $(composer config --global cache-dir)，禁用 chmod -R 777 及 sudo composer。
报 Permission denied 先看错误里写的路径
终端报错不会骗人，它明确告诉你哪个文件写不进去。比如：file_put_contents(/home/alex/myapp/vendor/autoload.php): Failed to open stream: Permission denied，问题就在 vendor/；又或者：Writing cache file ~/.composer/cache/repo/https---packagist.org/provider-laravel~framework.json 失败，那根源就是 ~/.composer/cache/ 归了 root。
- 立刻检查三处：
ls -ld vendor/、ls -ld composer.lock、ls -ld $(composer config --global cache-dir) - 只要输出第一列显示 owner 不是你的用户名（比如是
root或www-data），就是所有权错位，不是权限数字不够 - 别急着
chmod -R 777—— 这会让 CI 拒绝构建、安全扫描报警、Git 提交混乱，纯属掩耳盗铃
修复用 chown，不是 chmod
chown 是把目录“还给你”，chmod 是给所有人开后门。95% 的 Composer 权限问题，本质是“谁拥有它”，不是“它允许谁访问”。
- 修项目内：
sudo chown -R $USER:$USER vendor/ composer.lock - 修全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 如果整个
~/.composer都被sudo污染过：sudo chown -R $USER:$USER ~/.composer -
sudo这里只是临时提权改归属，不是让你以后都sudo composer install—— 后者才是污染源头
composer global require 报错，重点查 COMPOSER_HOME
很多人以为 global 是“装给系统用”，其实它只对当前 COMPOSER_HOME 对应的用户生效。如果你在终端里跑成功了，但 PHP-FPM 或 cron 里失败，大概率是因为它们用的是 www-data 用户，根本看不到你家目录下的 ~/.composer。
- 查当前生效路径：
composer config --global home，如果是空，说明走默认~/.composer - 如果输出是
/var/www/.composer这类非家目录，确认该路径 owner 是不是当前执行命令的用户 - 临时验证：
COMPOSER_HOME=/tmp/composer-test composer global require laravel/installer，能跑通就说明原路径归属有问题 - 永远别用
sudo composer global require—— 它会把二进制文件（如laravel）装进/root/.composer/vendor/bin，普通用户根本执行不到
安装 Composer 本身也别碰 sudo 管道
sudo curl -sS https://getcomposer.org/installer | php 这种写法是典型陷阱：管道右侧的 php 进程并不继承 sudo 权限，实际还是以普通用户身份运行，写 /usr/local/bin/composer 时照样被拒。
- 更稳妥的做法是装到用户空间：
php composer-setup.php --install-dir=$HOME/bin --filename=composer - 然后确保
$HOME/bin在$PATH里（加到~/.zshrc或~/.bashrc中：export PATH="$HOME/bin:$PATH"） - 如果非得装到
/usr/local/bin，必须让php进程本身有 root 权限：sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer - 顺手检查
umask：运行umask，推荐值是002或022；若为077，新生成文件默认无组/他人写权限，也会引发后续写入失败
最容易被忽略的一点：虚拟机、Docker 或共享目录中，主机和容器用户 UID 不一致会导致 chown 看似成功，实际文件在客户机里仍不可写。这时候得在客户机内单独调整 UID/GID 映射，或改用 bind mount 时指定 uid=1000,gid=1000 这类参数。
