根本不是权限位错误，而是文件归属（owner）不属于当前用户；应查ls -ld输出第三列是否为当前用户名，否则用chown修复而非chmod -r 777，尤其避免sudo composer install导致的归属污染。
根本不是权限位（rwx）错了，而是文件归属（owner）不属于你——查 ls -ld 输出里第三列是不是你的用户名，不是就立刻 chown，别碰 chmod -R 777。
报 Permission denied 时怎么快速定位问题路径
错误信息里带的完整路径就是线索，比如 file_put_contents(/home/alex/myapp/vendor/autoload.php) 失败，问题就在 vendor/；如果是 Writing cache file ~/.composer/cache/repo/https---packagist.org/ 失败，那就盯 ~/.composer/cache/。
- 立刻执行三行命令查归属：
ls -ld vendor/、ls -ld composer.lock、ls -ld $(composer config --global cache-dir) - 只要任意一行输出的第三列（属主）不是
$(whoami)（比如显示root），就是所有权错配 - 注意：路径里出现
/root/.composer或/var/www/.composer，说明COMPOSER_HOME被污染，得先查composer config --global home
用 chown 修复归属，而不是 chmod
chmod 控制“能不能读写”，chown 才决定“这东西归不归你”。误用 chmod -R 777 会让 vendor/bin/phpunit 这类可执行文件被 CI 工具或安全扫描器直接拒收，Git 提交时还会提示 ownership changed。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 修复项目内目录：
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——后者才是污染源头
为什么永远不要用 sudo composer install
它看似能跑，实则埋下持续性权限混乱：vendor/ 下的文件全变成 root 所有，后续 git pull、php artisan、IDE 自动索引都可能中断。尤其在 Docker 或 CI 环境中，这种临时 sudo 会破坏环境一致性。
- Docker 场景下，宿主机 UID 是 1001，容器却以 UID 0（
root）运行 → 挂载卷时加user:1001或 Dockerfile 里加USER 1001 -
composer global require报错？先查composer config --global home，如果输出是/root/.composer，说明环境已被sudo污染 - 插件干扰时，加
--no-plugins --no-interaction试试：composer install --no-plugins成功，大概率是某个全局插件在作祟
最容易被忽略的是嵌套归属问题：一旦 vendor/ 下混进 root 所有的子目录，composer update 可能只失败一半，连 chown -R 都救不回来，只能删掉 vendor/ 重来。
