PHP空白页主因是display_errors关闭且error_reporting级别过低，导致致命错误中断脚本而返回空body；入口加三行配置可快速启用错误显示，优先排查BOM、被引入文件、opcache及输出缓冲干扰。
空白页根本不是没报错，是错误被吞了
PHP 空白页几乎从不因为“什么都没发生”，而是 display_errors 被关了 + error_reporting 级别太低，导致 Fatal error、Parse error 这类致命问题直接中断脚本，浏览器收不到任何响应体。你看到的“白”，其实是 HTTP 200 响应里空的 body。
在入口文件顶部加三行，比改 php.ini 更快生效
尤其当你没权限改服务器全局配置时，这三行必须放在 <?php 后第一行（不能有空格、BOM、换行）：
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);
注意：display_startup_errors 很关键——它能捕获 require 文件时的解析错误，比如 config.php 里少了个括号，光开 display_errors 是看不到的。
- 如果加完仍空白，说明这三行根本没执行到，大概率是语法错误卡在解析阶段（比如
index.php开头就漏了<?php或写了却没开short_open_tag） - 如果加完出现错误，但信息被截断（如只显示
Parse error: syntax error, unexpected '}'没带文件名和行号），说明error_reporting没生效，检查是否被框架或 Composer 自动加载逻辑覆盖了
命令行 php -l 是最准的语法初筛工具
浏览器看不到的解析错误，php -l 一定能报出来。它不执行代码，只做词法与语法扫描，快且干净：
立即学习“PHP免费学习笔记（深入）”；
php -l index.php
常见反馈示例：
-
Parse error: syntax error, unexpected end of file in index.php on line 42→ 检查第 42 行附近是否漏了}或?> -
Parse error: syntax error, unexpected T_STRING in config.php on line 1→ 文件开头有 BOM 或非 PHP 内容（比如 UTF-8 BOM 的ef bb bf） - 返回
No syntax errors detected但页面还是空白 → 错误不在该文件，重点查它require或include的其他文件，尤其是配置类、路由定义等
错误堆栈里看不到文件路径？多半是 opcache 或输出缓冲干扰
有时开启 display_errors 后只看到 Fatal error: Uncaught Error: Class 'App\Http\Controllers\Controller' not found，但没指明哪行触发。这种“半截堆栈”常见于：
- opcache 启用且未更新缓存：执行
sudo systemctl reload php-fpm或opcache_reset()（需在可执行环境中调用） - 框架自动启用了
ob_start()，而错误发生在缓冲区 flush 前：临时在入口加ob_end_clean();再试 - 错误发生在
__autoload或spl_autoload_register回调里，堆栈被截断：在自动加载函数开头加file_put_contents('/tmp/autoloading.log', debug_backtrace(), FILE_APPEND);追踪调用链
真正难搞的不是报错本身，是错误信息被层层过滤后只剩一个空页面——盯住 display_startup_errors 和 php -l，这两个点没漏，90% 的空白页当场现形。
