报错路径在终端输出中带完整路径的那一行，如file_put_contents(/home/alex/myapp/vendor/autoload.php)中的/vendor/、composer.lock或~/.composer/cache等具体路径，需用ls -ld检查属主是否为当前用户，再用sudo chown -r $user:$user修复归属。
报错路径在哪？直接看终端里带完整路径的那一行
别被“权限不足”四个字带偏，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/ → 问题在全局缓存目录；Could not write to /var/www/myapp/composer.lock → 锁文件归属错了。
立刻执行这三行查归属：
ls -ld vendor/ls -ld composer.lockls -ld $(composer config --global cache-dir)
只要任意一行第三列（属主）显示 root 或 www-data，而你当前用户是 alex，就坐实了所有权错位——不是权限位不够，是东西不归你。
chown 是解药，chmod -R 777 是毒药
用 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都被污染了？sudo chown -R $USER:$USER ~/.composer
sudo 这里只用于临时提权跑 chown，不是让你去跑 sudo composer install——后者才是污染源头。
composer global require 报错？先查 COMPOSER_HOME
composer global require 不是“装给系统用”，而是装到当前 COMPOSER_HOME 对应的路径下。如果之前误用 sudo，二进制文件就被塞进了 /root/.composer/vendor/bin/，你的 shell 根本找不到它。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
查真实路径：composer config --global home。如果输出是 /root/.composer 或 /var/www/.composer，说明环境已被污染。
临时验证：COMPOSER_HOME=$HOME/.composer composer global require laravel/installer；长期解法：删掉污染路径（sudo rm -rf /root/.composer），再确保所有 global 命令都不带 sudo。
Docker/WSL 环境下权限错乱怎么处理
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 管用得多。
