答案是vendor目录报Permission denied主因是属主为root而非当前用户，需用ls -ld确认归属，再执行sudo chown -R $USER:$USER vendor/ composer.lock修复所有权，禁用chmod -R 777。
vendor目录报Permission denied，先确认是不是被root污染了
错误里出现 file_put_contents(/path/to/vendor/autoload.php) 或 rename(.../composer.lock) 这类路径，基本就能断定是 vendor 目录所有权错配。不是权限位（rwx）不够，而是目录“不归你管”。执行这三行快速验证：
-
ls -ld vendor/—— 如果第三列显示root，就是它 -
ls -ld composer.lock—— 同样检查，常被一起污染 -
ls -ld $(composer config --global cache-dir)—— 缓存目录也得看，尤其 CI 中容易卡在这儿
只要任意一行 owner 不是你当前用户名（$(whoami)），就别折腾 chmod，直接走 chown。
用chown重置所有权，不是chmod
chmod -R 777 vendor/ 是高危操作：CI 工具会拒收、Git 提示 ownership changed、后续 dump-autoload 可能静默失败。真正该做的是把控制权还给你自己：
- 修复项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock（注意vendor/末尾斜杠，否则子目录可能漏掉） - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 如果整个
~/.composer都是 root？直接重置：sudo chown -R $USER:$USER ~/.composer
sudo 这里只用于临时提权跑 chown，绝不是让你去跑 sudo composer install——后者才是污染源头。
重装前要不要删 vendor？看场景
单纯所有权错配，chown -R 足够；但如果已出现 autoload 加载失败、class not found、或 vendor/composer/installed.json 损坏，删掉更稳：
- 开发环境可直接：
rm -rf vendor/ composer.lock && composer install - CI/CD 或不能删
composer.lock的场景，先chown再试composer install --no-scripts，成功后再补composer run-script post-install-cmd - 嵌套污染常见：一次
sudo composer install可能让vendor/bin/下个别子目录属 root，ls -la vendor/才能发现；这种情况下chown -R仍有效，但若 autoload 结构已乱，重装反而更快
Docker 和 CI 环境要额外对齐 UID
本地修好了，一进容器又报错？大概率是 UID 不匹配：宿主机用户 UID 是 1000，容器却以 UID 0（root）运行，挂载进来的 vendor 在容器内属 root，但 Composer 用非 root 用户尝试覆盖 rename() 就会静默失败。
- Docker 启动时加：
docker run -u $(id -u):$(id -g)或 docker-compose.yml 里写user: "${UID:-1001}:${GID:-1001}" - GitHub Actions 中，避免缓存污染：加一步
sudo chown -R $GITHUB_ACTOR:$(id -g) vendor/，或干脆跳过缓存用--no-cache - Alpine 镜像要注意：
musl libc对renameat2()支持弱，加-v参数看是否卡在解包阶段
最易被忽略的是：错误信息里写的路径，未必是你要修的最终目标——Permission denied 往往是上游缓存或临时目录（如 /tmp 或 ~/.composer/cache/）归属错配引发的连锁反应，得顺着报错路径一级级查。
