vendor目录变不可读是因sudo或切换用户导致文件属主为root，普通用户PHP进程无权访问；应执行sudo chown -R $USER:$USER vendor、chmod 755/644并保留vendor/bin可执行位，且禁用sudo composer。
为什么 vendor 目录突然变成不可读？
常见于 Linux/macOS 下用 sudo composer install 或切换用户后执行过 Composer 命令，导致 vendor 里部分文件属主变成 root，普通用户运行 PHP（如 CLI 或 Web 服务器）时直接报 Permission denied 或 Class not found。这不是 Composer bug，而是 Unix 权限机制的自然结果。
快速修复：重置 vendor 所有者和权限
别删 vendor 重装——既慢又可能引入依赖漂移。直接修正权限更安全：
- 把整个
vendor目录及其内容的所有者改回当前用户（假设用户名是www-data或你的登录名）：sudo chown -R $USER:$USER vendor
- 确保目录可遍历、文件可读（PHP 运行时不需执行权限）：
find vendor -type d -exec chmod 755 {} \;find vendor -type f -exec chmod 644 {} \; - 特别注意
vendor/bin下的可执行脚本（如phpunit、laravel），需保留执行位：chmod +x vendor/bin/* 2>/dev/null || true
预防下次再出问题：永远别用 sudo composer
Composer 设计上不需 root 权限——它只写当前项目目录。以下行为会埋雷：
-
sudo composer install→vendor归 root - 用
root用户克隆项目并首次运行composer install - Web 服务器（如 Nginx+PHP-FPM）以
www-data运行，但你用个人账户执行了composer update，且未同步权限
正确做法：始终用项目所属用户操作；若需全局工具（如 laravel/installer），用 composer global require 并确保 ~/.composer/vendor/bin 在 $PATH 中，而非用 sudo。
CI/CD 或 Docker 环境中要注意什么？
在容器内或 CI 脚本中，容易因用户 UID 不一致导致权限错乱：
- Docker 构建时，避免用
USER root执行composer install，改用非 root 用户（如USER 1001）并在Dockerfile开头就创建该用户 - GitHub Actions 中，如果用了
cache: composer，确保缓存解压后执行chown -R $GITHUB_ACTOR /path/to/vendor（或直接跳过缓存，用--no-cache） - 某些共享主机限制
umask，可在composer.json的scripts中加钩子："post-install-cmd": "chmod -R u+rwX,go+rX,go-w vendor"
权限问题本质是用户与进程身份不匹配，不是 Composer 配置能绕开的。盯住谁在写、谁在读，比查文档更快定位。
