报Permission denied需先定位错误路径，再用ls -ld检查vendor/、composer.lock及全局缓存目录归属，若任一属主非当前用户（$(whoami)），即为所有权错位，应删vendor/与composer.lock后重装，或更换cache-dir路径并赋权。
报 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.lockls -ld $(composer config --global cache-dir)
只要任一输出第一列（如 drwxr-xr-x 12 root root）中 owner 不是你当前用户名（$(whoami)），就是所有权错位——不是权限数字太小，是“东西不归你”。
修 vendor/ 和 composer.lock：删比改更干净
误用 sudo composer install 后，vendor/ 下大量文件和子目录会变成 root 所有，后续普通用户不仅无法写入，某些包内嵌的 Phar 资源还可能因 chmod 破坏而静默失效。
- 最稳妥做法：
rm -rf vendor/ composer.lock，再用当前用户重跑composer install - 若不能删
composer.lock（如生产部署环境），至少确保vendor/目录本身归属正确：sudo chown $USER:$USER vendor，再补写权限：chmod u+w vendor - 注意：
composer create-project --no-interaction默认把vendor/设为只读，记得加chmod u+w vendor
修全局缓存和 ~/.composer：换路径比硬修更稳
缓存目录权限出问题，会导致所有命令卡在「写缓存失败」，哪怕 vendor/ 没事也照样报错。常见于首次用 sudo 安装 Composer 或全局 require 后残留的污染。
- 查当前缓存路径：
composer config --global cache-dir - 看归属：
ls -ld $(composer config --global cache-dir) - 修复方式二选一：
– 改归属：sudo chown -R $USER:$USER ~/.composer/cache
– 或换路径（推荐）：composer config --global cache-dir /home/$USER/.cache/composer，再手动创建并赋权：mkdir -p /home/$USER/.cache/composer && chown $USER:$USER /home/$USER/.cache/composer - 如果整个
~/.composer都属 root：sudo chown -R $USER:$USER ~/.composer，顺手加固：chmod -R u+rw ~/.composer
composer global require 装的命令找不到？重点查 COMPOSER_HOME 和 bin-dir
global 不是“装给系统用”，只是“装给当前 COMPOSER_HOME 对应的用户”。PHP-FPM、cron 或 Docker 容器里用 www-data 用户跑，根本看不到你家目录下的 ~/.composer。
- 查当前生效路径：
composer config --global home，如果是/var/www/.composer或/root/.composer，就得确认该路径 owner 是不是当前执行用户 - 验证是否路径污染：
COMPOSER_HOME=$HOME/.composer composer global require laravel/installer，能跑通就说明原路径才是问题 - 推荐长期方案：
mkdir -p ~/bin && composer config -g bin-dir ~/bin，再把~/bin加进PATH（如在~/.zshrc末尾加export PATH="$HOME/bin:$PATH"） - 永远别用
sudo composer global require——它会把laravel这类二进制文件装进/root/.composer/vendor/bin/，普通用户 shell 根本执行不到
真正容易被忽略的是：权限问题几乎从不源于“不够开放”，而是“归属错乱”。一旦某个目录被 root 占过，后续所有操作都会继承这个错误前提——所以别在报错后反复试 chmod 或加 sudo，先盯住 ls -ld 的输出，把 ownership 归还才是关键动作。
