答案是报错末尾完整路径指向vendor/、composer.lock或~/.composer/cache之一，需用ls -ld检查属主是否为当前用户，再执行sudo chown -r $user:$user修复归属，禁用chmod -r 777。
直接看报错末尾的完整路径，就能锁定问题目录——vendor/、composer.lock 或 ~/.composer/cache 三者之一大概率是真凶，修复归属比瞎 chmod 管用得多。
报错里那个路径到底指向哪？
终端错误信息末尾带完整路径的那行才是关键线索，比如：
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 config --global cache-dir)；
如果路径含 /root/.composer、/var/www/.composer 或 /mnt/c/ 开头，基本不是项目问题，而是环境配置错位。
怎么确认是不是归属问题？
执行这三条命令，重点看每行输出第三列（属主）是否等于 $(whoami)：
ls -ld vendor/
ls -ld composer.lock
ls -ld $(composer config --global cache-dir)
任意一行显示 root root 或 www-data www-data，而你的用户名是 alex，就坐实了归属问题。
注意：drwxr-xr-x 12 root root 中的 root 是属主，不是权限不足——chmod 解决不了归属问题。
chown 怎么修才安全？
别碰 chmod -R 777，它会让 vendor/bin/phpunit 这类可执行文件被 CI 拒绝，Git 提交时提示 ownership changed，还可能触发安全扫描拦截。
正确做法是归还所有权，且只对明确出问题的路径操作：
• 如果只是 vendor/ 归属异常：sudo chown -R $USER:$USER vendor/
• 如果 composer.lock 也被 root 占了：sudo chown $USER:$USER composer.lock
• 如果整个缓存目录都被污染：sudo chown -R $USER:$USER $(composer config --global cache-dir)
• 如果 ~/.composer 全是 root 的：sudo chown -R $USER:$USER ~/.composer，再补一句 chmod -R u+rw ~/.composer 防 umask 导致子目录不可写
WSL/Docker 环境下权限错乱怎么办？
在 WSL 中访问 /mnt/c/ 下项目时，mkdir(): Permission denied 常见，根本原因是 Windows NTFS 不支持 Linux uid/gid，chown 和 chmod 失效。
最稳解法是把项目移到 WSL 原生路径，如 ~/projects/myapp 再运行 composer install。
Docker 中避免用 root 用户执行 composer install，应启动容器时指定 UID/GID：docker run -u $(id -u):$(id -g)。
若必须 bind mount 宿主机目录，确保挂载时加 user: 参数，或提前在宿主机运行 chown -R $USER:$USER /path/to/project。
真正麻烦的从来不是报错本身，而是权限问题常跨层存在——可能表现在 vendor，根子却在缓存路径或 WSL 挂载方式上。每次遇到，先用 ls -ld 看清具体哪个路径被拒，比盲目 chmod 管用得多。
