Permission denied 报错95%是权限错配而非不足，主因是误用sudo导致vendor/或~/.composer目录属主为root，需用chown -R $USER:$USER修复归属并重装。
Composer 安装失败报 Permission denied，95% 不是权限不够，而是权限错配——文件属主是 root，而你正以普通用户运行命令。
vendor/ 目录写入失败：先看报错路径再查属主
终端报错里带 vendor/autoload.php 或 vendor/composer/installed.json？直接锁定问题在 vendor/ 目录。别急着 chmod -R 777，先确认归属：
- 运行
ls -ld vendor/，如果输出第一列是drwxr-xr-x 3 root root，说明它被sudo composer install污染过 - 修复命令：
sudo chown -R $USER:$USER vendor/（$USER会自动展开为你当前用户名） - 顺手检查
composer.json和composer.lock所在目录是否也属 root：ls -ld . composer.json composer.lock，是的话一并修复 - 修复后立刻删掉
vendor/和composer.lock，再用普通用户重跑composer install
全局缓存卡在 Writing cache file：检查 ~/.composer/cache
报错含 Writing cache file ~/.composer/cache/repo/https---packagist.org/？说明全局缓存目录被 root 占了。这是误用 sudo composer global require 的典型后遗症：
- 确认缓存路径：
composer config --global cache-dir - 查看归属：
ls -ld $(composer config --global cache-dir) - 若属主不是你，执行：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 清理残留：
composer clear-cache（此时不应再报错） - 极端情况：整个
~/.composer都属 root，直接sudo chown -R $USER:$USER ~/.composer
laravel、phpunit 命令找不到：bin-dir 权限 + PATH 双问题
composer global require laravel/installer 成功，但输 laravel 提示 command not found？问题常出在两处：
- 先查 bin 目录在哪：
composer config -g bin-dir，默认是~/.composer/vendor/bin - 检查该路径权限：
ls -ld $(composer config -g bin-dir)，若属主非你，运行sudo chown -R $USER:$USER $(composer config -g bin-dir) - 确保它已加入
$PATH：在~/.zshrc或~/.bashrc加export PATH="$HOME/.composer/vendor/bin:$PATH"，然后source ~/.zshrc - 更稳妥做法：把 bin-dir 改到用户可完全控制的路径，如
mkdir -p ~/bin && composer config -g bin-dir ~/bin && export PATH="$HOME/bin:$PATH"
Docker 或 Laravel 开发环境中的 UID/GID 错位
在 docker-compose 环境下跑 composer install 失败，或 Web 请求时提示 Unable to write to directory，大概率是宿主机与容器用户 ID 不一致：
- 查容器内 PHP 进程 UID：
docker-compose exec php id -u，应和宿主机当前用户 UID 一致（通常是 1000） - 查宿主机项目目录归属：
ls -ld ./src（假设挂载点是./src:/var/www/html），UID 应匹配 - 若不匹配，在
docker-compose.yml的args中显式传入：- UID=${UID:-1000}，并在宿主机确保UID环境变量已设 - Web 服务器（如 nginx）需读取
vendor/，但不需要写；若用www-data运行，可将当前用户加进该组：sudo usermod -a -G www-data $USER，再设storage/目录组可写
真正麻烦的不是修复动作本身，而是同一台机器上混用 sudo composer 和普通用户命令后，vendor/、~/.composer、composer.lock 三处归属可能各自为政——必须逐个 ls -ld 确认，不能只修一处就以为完事。
