根本原因是目录所有权错配，而非权限不足；报错路径即问题目录，需用ls -ld检查vendor/、composer.lock及全局缓存目录归属，若属主为root，则执行sudo chown -R $USER:$USER修复。
根本不是脚本没权限执行，而是它试图写入的目录（比如 vendor/、composer.lock 或缓存路径）归了 root，普通用户被操作系统直接拦住。
报错路径就是问题目录，别猜，直接查归属
终端报错里明确带出的路径，就是你要修的地方。常见三类：
-
file_put_contents(/path/to/vendor/autoload.php): Permission denied→ 查vendor/ -
Could not write to /path/to/composer.lock→ 查composer.lock -
Writing cache file ~/.composer/cache/...→ 查$(composer config --global cache-dir)
立刻运行这三行确认归属：
ls -ld vendor/ ls -ld composer.lock ls -ld $(composer config --global cache-dir)
只要任意一行输出第三列（属主）不是当前用户名（$(whoami)），比如显示 root，就坐实是所有权错配。
chown 是解药，chmod -R 777 是毒药
改的是“谁拥有它”，不是“能不能读写”。用 chmod -R 777 不仅无效，还会导致：
-
vendor/bin/phpunit被 CI 工具或安全扫描器拒收 - Git 提交时提示
ownership changed - 后续
composer update可能只失败一半，chown -R都救不回来
正确修复动作（复制粘贴即可）：
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 composer install
一次 sudo composer install 就够毁掉整个开发流：
-
vendor/下所有文件变成root所有 - 某些
post-install-cmd脚本以root身份执行，可能意外往/usr/local/bin写东西 -
HOME环境变量被覆盖成/root，导致auth.json、插件配置全部错位 - Docker 构建中若用了
USER root，镜像里vendor/属root，但容器运行时切到非root用户就彻底失权
sudo 这里只是临时提权跑 chown，不是让你去跑 sudo composer install——后者才是污染源头。
Docker / WSL / CI 环境下权限更脆，得提前防
这些环境里 UID 不匹配、挂载路径跨系统、基础镜像默认属 root，会让问题更隐蔽：
- Docker 构建时，显式设置工作目录归属：
RUN chown -R www-data:www-data /app - GitHub Actions 中，缓存解压后加一步：
chown -R $GITHUB_ACTOR /path/to/vendor - 本地 WSL 或 macOS 上，避免用
sudo启动终端，否则整个 shell 会继承root权限
最易被忽略的一点：所有修复都必须在删掉污染产物（vendor/ 和 composer.lock）之后再执行，否则旧的 root 子目录可能嵌套残留，继续卡住后续操作。
