答案是vendor目录报permission denied主因是属主为root而非权限数字不足，应先用ls -ld vendor/确认归属，若显示root root则删vendor和composer.lock后以当前用户重装，或chown修正属主并chmod u+w vendor。
vendor目录报Permission denied，先看属主再动手
看到file_put_contents(/path/vendor/autoload.php): Failed to open stream: Permission denied，别急着chmod -R 777 vendor/。90%的问题是目录属主为root，而不是权限数字不够。执行ls -ld vendor/，如果第三、四列显示root root，就坐实了归属错位。
顺手检查composer.lock和缓存路径：ls -ld composer.lock、ls -ld $(composer config --global cache-dir)。任意一个属root，都得一并修复——否则重装后可能立刻复现。
删 vendor 比递归 chown 更安全
sudo chown -R $USER:$USER vendor/看着省事，但风险高：Phar包里的只读资源可能被破坏，符号链接目标会被误改，某些post-install-cmd脚本依赖原始权限位，强行覆盖后反而导致后续composer update失败一半。
- 最稳妥做法：删掉整个
vendor/和composer.lock，再用当前用户跑composer install - 若
composer.lock不能删（如生产部署），至少确保vendor/目录本身归属正确：sudo chown $USER:$USER vendor/+chmod u+w vendor/ - 删之前先确认项目根目录可写：
touch test && rm test，避免重装卡在第一步
Web 环境下要兼顾 www-data 组权限
Nginx 或 PHP-FPM 通常以www-data（Ubuntu/Debian）或apache（CentOS）身份运行，但你本地用alex执行composer install，结果vendor/归alex，www-data只能读、不能执行vendor/bin/phpunit这类脚本，甚至 autoload 失败。
安全做法是设双归属：sudo chown -R alex:www-data ./，再分层设权：
-
find vendor/ -type d -exec chmod 755 {} \;（目录需执行位才能遍历） -
find vendor/ -type f -exec chmod 644 {} \;（PHP 文件无需执行权） -
chmod +x vendor/bin/* 2>/dev/null || true（单独放开可执行入口） -
sudo usermod -a -G www-data alex（把你加进www-data组）
Docker 和 CI 场景下权限错得更隐蔽
宿主机挂载目录进容器，默认属root，但容器内用 UID 1001 运行，vendor/自然写不了。GitHub Actions 缓存解压后也常继承错误 UID。
关键不是改权限，而是对齐用户上下文：
- Docker 运行时强制 UID 对齐：
docker run -u $(id -u):$(id -g) -v $(pwd):/app php:8.3 composer install - CI 脚本里不依赖缓存，或加修复步骤：
rm -rf vendor && composer install（比chown -R更干净） - 别忽略缓存目录这个“上游病灶”：
composer config --global cache-dir返回的路径一旦属root，所有全局操作都会连锁失败
真正麻烦的从来不是报错本身，而是权限问题常跨层存在——表现在vendor，根子却在缓存、Docker 卷挂载方式或umask设置上。每次遇到，先用ls -l看清具体哪个路径被拒，比盲目chmod 777管用得多。
