PHP空白页主因是错误被静默终止，需检查display_errors和error_reporting配置、exit/die中断、错误日志、输出缓冲及BOM问题。
PHP 空白页（即浏览器打开后一片白，无任何输出、无错误提示）绝大多数情况下不是“没代码”，而是 PHP 执行中途被静默终止了。核心排查方向是：**错误是否被关闭？脚本是否提前 exit/die？是否有致命错误但 display_errors 关闭？输出是否被缓冲或截断？**
检查 display_errors 和 error_reporting 是否启用
这是最常见原因：PHP 报错了，但配置禁止显示，导致页面空着不吭声。
-
display_errors必须设为On（开发环境），生产环境也建议临时开启用于诊断 -
error_reporting建议设为E_ALL，否则像E_NOTICE或E_DEPRECATED错误会被忽略，而某些 NOTICE 可能触发后续 fatal（如未定义变量参与数组操作） - 修改位置有三处，优先级从高到低：
.htaccess→php.ini→ 代码中用ini_set() - 在脚本开头加这两行可强制生效（绕过配置限制）：
ini_set('display_errors', '1');
error_reporting(E_ALL);
如果加上后立刻看到报错，说明就是这个原因；如果仍空白，继续往下查。
确认是否因 exit()、die() 或未捕获异常中断执行
空白页常出现在某处提前终止，后面代码根本没跑。尤其注意：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
立即学习“PHP免费学习笔记（深入）”；
- 数据库连接失败后直接
die("connect failed")，但字符串被输出缓冲拦截或被 header() 后的输出控制逻辑丢弃 - 使用
require/include加载不存在文件时，默认触发Warning并继续执行；但若用了require_once且路径错误 +opcache.revalidate_path=Off，可能静默失败 - 未用
try/catch捕获的Fatal error（如调用不存在的方法）会立即终止，且在display_errors=Off下完全不可见 - 检查日志：
tail -f /var/log/php_errors.log（路径以phpinfo()中error_log值为准）
查看 PHP 错误日志而非依赖浏览器输出
浏览器看到空白 ≠ 没错误。PHP 默认把错误写进日志，而不是发给前端。
- 运行
phpinfo();查看error_log配置项指向哪（常见如/var/log/php-fpm/www-error.log或/usr/local/var/log/php/error.log） - 用
grep -i "fatal\|error\|warning" /path/to/error.log | tail -20快速定位最近报错 - 如果日志为空，检查权限：
ps aux | grep php看运行用户（如www-data），确保该用户对日志目录有写权限 - Apache 用户还需确认
ErrorLog指令是否覆盖了 PHP 错误（有时 Apache 错误日志里也有线索）
输出缓冲与 UTF-8 BOM 导致的隐形截断
页面看似空白，实则 HTML 已输出但被浏览器拒绝渲染——典型诱因是 BOM 或缓冲未刷新。
- 用
hexdump -C yourfile.php | head -5检查文件开头是否有ef bb bf（UTF-8 BOM），有则用编辑器另存为「UTF-8 无 BOM」格式 - 如果脚本中调用了
ob_start()但没ob_end_flush()，且最后没echo，会导致全部输出被丢弃 - 某些框架或 CMS（如早期 WordPress 插件）会在
wp-config.php后多一个空行或空格，导致 headers already sent 错误，进而让后续echo失效 - 临时加一句
echo 'DEBUG'; exit;在文件最顶部，确认是否真的一行都没执行
空白页问题真正麻烦的地方往往不在语法，而在环境配置与执行链路的隐性断点——比如 opcache 缓存了旧字节码、SELinux 拦截了日志写入、或 nginx 的 fastcgi_intercept_errors on 把 PHP 错误转成 502 页面。动手前先看日志，比猜更可靠。
