必须让vendor目录所有者和权限适配PHP-FPM实际运行用户（如www-data），而非Nginx用户；查ps aux | grep php-fpm或www.conf确认user/group，再chown -R user:group vendor/，find vendor -type d -exec chmod 755 {} \;，find vendor -type f -exec chmod 644 {} \;，chmod +x vendor/bin/*，最后用require_once 'vendor/autoload.php'验证。
不能直接给 Nginx 用户“授予 vendor 读取权限”，而是要让 vendor 目录的所有者和权限适配 PHP-FPM 实际运行的用户（通常是 www-data 或 nginx），否则 500 错误或 Class not found 就会静默出现。
确认 PHP-FPM 真正以哪个用户运行
别猜，直接查。Nginx 本身不执行 PHP，是 PHP-FPM 进程在读 vendor；而 PHP-FPM 的用户由其配置决定，和 Nginx 用户名常不一致：
- 运行
ps aux | grep php-fpm，看 master 进程的 USER 列（常见是www-data、nginx或apache） - 或查 PHP-FPM pool 配置文件（如
/etc/php/*/fpm/pool.d/www.conf），找user =和group =行 - 宝塔面板用户注意：默认用
www用户，不是www-data—— 这点极易踩坑
修复 vendor 所有者和权限的最小必要操作
目标是让 PHP-FPM 用户能遍历目录、读取文件，但不需执行权限（vendor/bin 除外）。以下命令必须按顺序执行，且不能用 sudo composer install 回滚：
- 重设所有者：
sudo chown -R www-data:www-data vendor/（把www-data换成你上一步确认的实际用户） - 设目录可遍历：
find vendor -type d -exec chmod 755 {} \; - 设文件只读：
find vendor -type f -exec chmod 644 {} \; - 单独放开 bin 脚本：
chmod +x vendor/bin/* 2>/dev/null || true
为什么不能只改 chmod 755 vendor 就完事
单纯递归改整个 vendor 权限看似省事，但会出两类问题：
-
vendor/autoload.php若被设成 755，PHP-FPM 可能因安全策略拒绝执行（尤其启用了open_basedir或 SELinux） -
vendor/composer/下的 JSON 文件、锁文件若被设成可执行（755），某些严格模式的 Web 服务器会拒读 - 更隐蔽的是：部分包的
vendor/{package}/src/里混着 shell 脚本，误加执行位可能引发解析错误
部署后必须验证的两个检查点
权限改完不等于万事大吉，还得确认 PHP 进程真能加载：
- 写个临时脚本
test-autoload.php放在 Web 根目录：<?php require_once 'vendor/autoload.php'; echo "OK";
，用浏览器或curl访问，看是否返回 OK 而非 500 - 检查 PHP 错误日志（如
/var/log/php*-fpm.log或宝塔的站点日志），搜索failed to open stream或Permission denied
最常被忽略的一点：宝塔或 Docker 环境下，www 用户和 www-data 用户常被当成一回事，但它们 UID/GID 不同、家目录不同、shell 权限也不同——所有权限修复必须基于实际运行 PHP 的 UID，而不是“看起来像”的用户名。
