PHP脚本500或空白主因是父目录缺x权限及open_basedir限制；需确保路径各级目录有x权限、脚本有r权限，检查php-fpm用户组匹配、SELinux/AppArmor策略及权限叠加影响。
chmod 后 PHP 脚本直接 500 或空白页面
不是所有文件改了权限就能跑起来。Web 服务器（如 Apache、Nginx）运行 PHP 时，实际是用 www-data（Debian/Ubuntu）或 apache（CentOS/RHEL）这类低权限用户去读取和执行脚本的。如果你只对文件执行了 chmod 755，但父目录没有可执行（x）权限，PHP 进程根本进不去目录，连文件都打不开，直接 500 或静默失败。
常见错误现象：Permission denied 出现在 error log 里，但浏览器只显示空白；或者 file not found 却路径明明存在。
- 确保从 Web 根目录开始，每一级父目录都有
x权限（即至少755对于目录） - PHP 脚本文件本身需有读权限（
r），如果是 CGI/FPM 模式下执行，还需要执行权限（x）——但绝大多数现代部署（mod_php、php-fpm）其实只要求读权限 - 别盲目
chmod -R 777，这会让 Web 服务读到不该读的配置文件（比如.env、config.php），反而引发安全告警或被自动拦截
php-fpm 下用户组不匹配导致权限拒绝
当 PHP 用 php-fpm 运行时，www-data 用户可能不属于你期望的文件所属组，而你又依赖组权限（比如把文件属组设为 www-data 并给组 rw），结果还是报错。关键要看 www.conf 里 user 和 group 的配置是否与文件属主一致。
检查命令：ps aux | grep php-fpm 看 worker 进程跑在哪个用户下；再用 ls -l 对比脚本和关键资源（如缓存目录、日志文件）的属主/属组。
立即学习“PHP免费学习笔记（深入）”；
- 修改 php-fpm pool 配置后必须重启服务：
sudo systemctl restart php*-fpm（版本号要填对，如php8.1-fpm） - 如果脚本需要写日志或上传文件，目标目录不能只靠“同组可写”，还得确认该目录的 setgid 位是否开启（
chmod g+s），否则新创建的文件可能继承错组 - 用
id -nG www-data查看该用户实际所属的全部组，避免遗漏隐式组权限
open_basedir 或 safe_mode（已废弃）干扰真实权限判断
即使系统级权限全开，PHP 自身的限制也可能让你白调 chmod。最常踩坑的是 open_basedir：它会强制限定脚本能访问的文件路径范围。一旦脚本试图 require 或 file_get_contents 一个不在该白名单里的路径，哪怕权限 777，也会报 failed to open stream: Operation not permitted。
这个设置可能来自多个地方：php.ini、www.conf（php-fpm）、虚拟主机配置（Apache 的 php_admin_value 或 Nginx 的 fastcgi_param PHP_VALUE）。
- 临时验证是否是它惹的祸：在脚本开头加
echo ini_get('open_basedir');，输出为空才表示没启用 - 若启用了，注意路径末尾要带
/（如/var/www/html/），否则子目录不被包含 -
safe_mode在 PHP 5.4+ 已移除，但有些老旧环境仍残留配置项，grep 一下php.ini确认是否误启
SELinux 或 AppArmor 拦截（Linux 发行版特有）
在 CentOS/RHEL（SELinux）或 Ubuntu（AppArmor）上，即使 chmod 和属主都对，脚本仍可能因内核级 MAC（强制访问控制）被拒。典型表现是 error log 里出现 Permission denied，但 ls -l 看一切正常，且 setenforce 0 临时关闭 SELinux 后立刻恢复正常。
查 SELinux 是否启用：sestatus；查最近拒绝记录：sudo ausearch -m avc -ts recent | audit2why（需要 policycoreutils-python-utils 包）。
- 不要长期
setenforce 0，应生成并加载对应策略：audit2allow -a -M myphp && semodule -i myphp.pp - AppArmor 下检查：
aa-status，然后看对应 profile 是否允许network tcp（如果脚本要连 MySQL）、/var/www/** rwk等 - 这类问题不会出现在纯 Docker 容器（除非显式启用）或 macOS/Windows 上，排查前先确认系统类型
实际权限问题往往不是单点故障，而是 chmod、属主、PHP 运行用户、Web 服务器模块、内核安全模块层层叠加的结果。最容易被忽略的，是父目录缺失 x 权限，以及 open_basedir 这种“看不见的墙”。
