php 8.0白屏或500错误主因是错误被拦截消失，需在public/index.php首行加ini_set('display_errors','1')、error_reporting(e_all)和ini_set('display_startup_errors','1')强制报错，并检查日志路径可写及tp8异常类是否误用原生exception。
PHP 8.0 白屏或 500 错误，绝大多数情况不是代码写崩了，而是错误被层层拦截后彻底“消失”——你看到的空白页，其实是 PHP 连错误都来不及吐出来就挂了。
入口文件顶部加三行强制报错
这是最快暴露真实问题的手段，绕过所有框架和 Web 服务器干扰：
-
ini_set('display_errors', '1')和error_reporting(E_ALL)必须放在public/index.php第一行 PHP 标签后、任何require或include之前； - 如果还看不到错误，补上
ini_set('display_startup_errors', '1')，它能捕获autoload.php加载失败这类早期致命错误； - 若仍白屏，说明错误发生在更底层（如扩展未加载、PHP 解析器启动失败），此时必须查日志或 CLI 验证。
查 PHP 错误日志前先确认它真在写
很多环境看似配置了日志，实则路径不可写、log_errors 被关掉，或 SELinux 拦截了写入：
- 运行
php -i | grep -E "log_errors|error_log"，确认log_errors => On且error_log指向绝对路径（如/var/log/php_errors.log）； - 执行
ls -l /var/log/php_errors.log，若文件不存在，用sudo touch创建并chown给 Web 进程用户（如www-data或nginx）； - 手动写入测试：
echo "test" >> /var/log/php_errors.log，再tail -n 1 /var/log/php_errors.log看是否成功； - 刷新页面后立刻
tail -f /var/log/php_errors.log，真实错误几乎都在最后一两行。
ThinkPHP 8.0 特有陷阱：原生 Exception 不被接管
TP8.0 的异常处理器默认只捕获 \think\exception\* 子类，throw new \Exception() 会被 PHP 底层直接终止进程，导致 500 + 白屏，且不进框架日志：
- 在控制器里写一句
throw new \Exception('test');，访问该接口——若看到白屏或原始堆栈，说明框架没接管； - 必须统一改用
throw new \think\exception\HttpException(500, 'xxx')或对应业务异常类； - 检查
app/exception/Handler.php中的render()方法，里面不能有echo或print_r，否则会触发“headers already sent”，二次导致 500。
runtime/log 目录权限和 PDO 连接失败是隐形杀手
这两个问题不会报明确错误，但会静默中断初始化流程：
- 执行
ls -ld runtime/ runtime/log/，确保 Web 进程用户对该目录有rwx权限； - 若用 Swoole 或 RoadRunner，
LOG_PATH可能指向/tmp/think-log，需单独检查该路径是否存在且可写； - PDO 连接失败时 TP8.0 默认只返回通用 500，真实原因藏在
PDOException::getMessage()里，临时在app/common.php开头加报错三行，或命令行直连验证：php -r "new PDO('mysql:host=127.0.0.1;dbname=test', 'user', 'pass');"； - 重点看 message 中的错误码：
[2002] Connection refused（MySQL 服务没启）、[1045] Access denied（账号密码错）、[2002] No such file（socket 路径不对）。
真正卡住人的，往往不是语法错或逻辑错，而是 runtime 目录属主不对、PDO 异常被吞、或者你以为开了 display_errors 其实被 Nginx 的 fastcgi_intercept_errors on 拦截了——这些细节不亲手敲命令验证，光看文档永远找不到。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
