95%的Composer权限报错是目录属主错配，应先用ls -ld检查vendor/、composer.lock和全局缓存目录属主是否为当前用户，非则执行sudo chown -R $USER:$USER修复，而非chmod。
别改 chmod，先查属主——95% 的本地 Composer 权限报错，根源是 vendor/、composer.lock 或 ~/.composer 被 root 占了，不是你没权限，而是目录不认你。
看报错路径立刻锁死问题目录
终端错误里带的完整路径就是线索，不用猜。比如出现 file_put_contents(/home/alex/myapp/vendor/autoload.php): Permission denied，问题就在 vendor/；如果提示 Writing cache file ~/.composer/cache/repo/https---packagist.org/ 失败，就去查全局缓存目录。
立刻执行这三行命令定位：
ls -ld vendor/ls -ld composer.lockls -ld $(composer config --global cache-dir)
只要任意一行输出第三列（属主）不是 $(whoami)（比如显示 root root），就确认是所有权错配。
chown 修复归属，不是 chmod 放宽权限
chmod -R 777 不但无效，还会让 vendor/bin/phpunit 这类可执行文件被 CI 拒收、Git 提示 ownership changed。真正该做的是把目录“还给你”：
- 项目内修复：
sudo chown -R $USER:$USER vendor/ composer.lock - 全局缓存修复：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都归 root？直接重置：sudo chown -R $USER:$USER ~/.composer
sudo 这里只是临时提权跑 chown，不是让你以后都加 sudo 运行 composer install——后者才是污染源头。
为什么删 vendor/ 有时比修权限更干脆
如果已经用过 sudo composer install，vendor/ 下可能出现混杂属主（部分子目录是 root，部分是你自己），chown -R 可能漏掉嵌套层级，后续 composer update 会卡在中途失败。
开发环境推荐一步到位：
- 删掉
vendor/和composer.lock - 确认当前用户没切错（
whoami输出是你自己） - 用普通用户执行
composer install
它会按原始依赖精确还原，且所有文件属主是你自己。
Docker 或 WSL 环境下容易忽略 UID 错位
本地好好的，一进容器或 WSL 就报错？本质是 UID 不一致：宿主机用户 UID 是 1001，容器内默认用的是 0（root）或另一个 UID，挂载卷后文件不可写。
不要在容器里 sudo composer install，改用匹配 UID 的用户启动：
- Docker：
docker run -u $(id -u):$(id -g) ... - CI 脚本中加清理步骤：
rm -rf vendor/ composer.lock && composer install - 构建镜像时显式设归属：
RUN chown -R www-data:www-data /app
最易被忽略的一点：所有修复动作，必须在删掉已被 sudo 污染的 vendor/ 和 composer.lock 后再执行——否则你在给一个已失效的结构打补丁。
