vendor目录属主变为root是因为用sudo执行了composer命令，修复需sudo chown -R $USER:$USER vendor/并禁用sudo composer。
为什么 vendor 目录属主变成 root 了
典型现象是 require(): Failed opening required 'vendor/autoload.php' 或 PHP-FPM 报 Permission denied，但 ls -l vendor/autoload.php 显示属主是 root。根本原因不是 Composer 本身有问题，而是你或 CI 脚本用 sudo composer install、sudo composer update 或 sudo composer dump-autoload 执行过命令——这些操作让生成的所有文件（包括 vendor/composer/autoload_*.php）都被标记为 root 所有。
修复：必须 chown，不能只 chmod
chmod 改权限没用，因为：
• 下次 dump-autoload 会覆盖 autoload_*.php，新文件仍属 root
• vendor/autoload.php 是入口文件，权限正确但属主不对，PHP 进程仍无法读取
• 777 等宽松权限会被安全扫描器拦截，CI 工具可能直接拒绝部署
正确做法是归还整个目录树所有权：
-
sudo chown -R $USER:$USER vendor/（Linux/macOS） -
sudo chown $USER:$USER composer.lock（如果 lock 文件也被 root 占了） - Windows WSL 用户注意：确保
$USER是当前 shell 用户，不是 Windows 用户名
预防：从源头禁用 sudo composer
后续所有操作都应避免提权：
- 永远不用
sudo composer install—— 即使提示“Permission denied”也要先查属主，而不是硬上 sudo - CI 脚本里检查运行用户：
echo "Running as $(whoami)"，确保不是root或0 - Docker 构建时显式切用户：
RUN adduser -u 1001 -D app && USER app，再跑composer install - 本地开发用
docker run -u $(id -u):$(id -g)启动容器，避免容器内 UID 和宿主机错位
最容易被忽略的点
vendor/composer/ 下所有 autoload_*.php 文件（如 autoload_psr4.php、autoload_classmap.php）都是动态生成的，每次 dump-autoload 都会重写。它们的属主和权限完全继承自执行命令的用户 —— 不是你在 composer.json 里能配出来的，也不是 umask 单独能兜住的。所以修复和预防的核心，始终是“谁在运行命令”，而不是“怎么改权限”。
