直接原因是php进程用户（如www-data或nginx）对文件或其任意父目录缺少读（r）或执行（x）权限，或者selinux强制策略拦截访问；需用namei -l检查权限链、ls -z核验selinux上下文，并确保目录755、文件644。
直接原因是 PHP 进程用户（如 www-data 或 nginx）对文件或其任意父目录缺少读（r）或执行（x）权限，或者 SELinux 强制策略拦截了访问 —— 不是 PHP 本身出错，而是操作系统层的权限链断裂。
Web 服务器访问 PHP 文件报 403/500 或空白页，先查路径权限链
Apache/Nginx 不是“打开”PHP 文件，而是以进程用户身份逐级进入路径、读取文件。只要 /var/www/html/index.php 中任一层（比如 /var、/var/www、/var/www/html）对 Web 用户无 x 权限，就会卡在“无法进入目录”，最终表现为 Permission denied。
- 用
namei -l /var/www/html/index.php一次性列出每级目录的属主、组、权限，快速定位哪一级缺失x - 目录必须设为
755（即rwxr-xr-x），确保 Web 用户有执行位；文件设为644（rw-r--r--）即可，无需x - 别用
chmod -R 755 /var/www/html：它会把 PHP 文件也设成可执行，带来安全隐患 - 如果属主是
ftpuser而 Web 进程是www-data，不能只靠属主权限，得靠组权限或“其他”读权限兜底
CLI 下运行 php script.php 却报 Permission denied
这不是 PHP 的问题，是 Linux 对 ./script.php 的执行机制触发的 —— 系统看到 ./ 就尝试直接执行该文件，而它没有 x 位。
- 正确做法是显式调用解释器：
php script.php，此时只需文件有r权限（644足够） - 非要
./script.php运行？先加 shebang 行（如#!/usr/bin/env php），再chmod u+x script.php -
chmod +x *.php批量操作极危险：Web 目录下被上传的恶意 PHP 文件可能因此被直接执行 - 很多脚本依赖
$_SERVER或 Web 环境配置，强行./运行会导致逻辑异常，优先用php -f调试
rename()、file_put_contents() 失败，但 chmod 777 也没用
这是 SELinux 在起作用。即使文件属主、权限全对，SELinux 仍可能禁止 httpd 进程执行 rename、写入或移动操作 —— 它和传统权限完全独立。
- 先验证：
sudo setenforce 0临时切到 permissive 模式，再试操作；成功就确认是 SELinux 导致 - 生产环境别禁用 SELinux，改用
chcon -R -t httpd_sys_rw_content_t /path/to/dir赋予可写上下文 - 永久生效需配合
semanage fcontext和restorecon，否则系统更新或restorecon命令会清掉chcon设置 -
ls -Z /path查看当前 SELinux 类型：写入目录应为httpd_sys_rw_content_t，普通静态文件应为httpd_sys_content_t
真正容易被忽略的不是某一行 chmod 命令，而是权限链中“某一级目录没 x”、或 SELinux 上下文类型不匹配 —— 这两类问题不会在 ls -l 里直接暴露，必须用 namei -l 或 ls -Z 主动检查。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
