php报错怎么查看_定位PHP致命错误与警告的方法【教程】

PHP报错需主动暴露而非依赖白屏：开发环境开启display_errors=On、error_reporting=E_ALL、log_errors=On并配置error_log路径，重启服务生效；用error_get_last()兜底捕获致命错误，CLI模式直接输出完整报错，结合set_error_handler与register_shutdown_function实现全量错误拦截，同时确保日志可写、带时间戳和PID。

PHP 报错不能只靠浏览器白屏或空白响应来猜——关键得让错误真正“露出来”，否则连 Parse error 都看不到，更别说定位 Fatal error 或 Warning。

开启 PHP 错误显示与日志记录

默认情况下，很多生产环境会关闭 display_errors，导致错误被静默吞掉；而 error_log 若未配置，错误就无处可查。

• display_errors = On（仅开发环境启用，切勿在生产环境打开）
• error_reporting = E_ALL（覆盖 E_DEPRECATED、E_NOTICE 等所有级别）
• log_errors = On（必须开启，才能写入日志）
• error_log = /var/log/php/error.log（指定绝对路径，确保 Web 服务器用户有写权限）

修改后需重启 Web 服务（如 sudo systemctl restart apache2 或 sudo systemctl restart php-fpm），否则配置不生效。

用 error_get_last() 捕获最后一条致命错误

error_get_last() 是少数能“事后”拿到刚发生的 Fatal error 的方式，适用于脚本末尾兜底检查，但无法捕获已终止执行的致命错误（比如 Call to undefined function 后脚本直接退出，后续代码不执行）。

if ($error = error_get_last()) {
    if (in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])) {
        error_log('FATAL: ' . $error['message'] . ' in ' . $error['file'] . ':' . $error['line']);
    }
}

注意：它只返回**最近一次错误**，且仅对非终止类错误（如 Warning）更可靠；Fatal error 发生后，该函数可能根本没机会运行。

在 CLI 模式下直接看到完整报错

Web 环境容易被 Nginx/Apache 层级配置掩盖错误，而 CLI 模式最干净。运行 php script.php，错误会直接输出到终端，含文件名、行号、错误类型和堆栈（如果启用了 display_errors）。

• 确保 CLI 使用的 php.ini 和 Web 使用的不是同一份（可用 php --ini 查看）
• CLI 默认 error_reporting 通常是 E_ALL，但 display_errors 可能为 Off，需手动确认
• 遇到 Segmentation fault 这类底层崩溃，需用 php -d zend_extension=xdebug.so script.php 配合调试器定位

用 set_error_handler + register_shutdown_function 组合抓取全量错误

这是最接近“全拦截”的做法：set_error_handler 捕获 Warning/Notice，register_shutdown_function 在脚本终止前检查是否发生了 Fatal error。

set_error_handler(function($errno, $errstr, $errfile, $errline) {
    error_log("PHP $errno: $errstr in $errfile:$errline");
});

register_shutdown_function(function() {
    if ($error = error_get_last()) {
        if (in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])) {
            error_log("SHUTDOWN FATAL: {$error['message']} in {$error['file']}:{$error['line']}");
        }
    }
});

注意：该组合仍无法捕获 memory_limit 超限或 max_execution_time 中断这类 Zend 引擎级终止；它们不会触发 error_get_last()，需依赖 error_log 文件或系统监控。

真正难定位的从来不是报错文字本身，而是错误发生时上下文已丢失——变量值、调用链、请求参数全没了。所以别只盯着“怎么显示错误”，先确保 error_log 路径可写、日志轮转不丢数据、每条日志带时间戳和 PID，这些比花哨的前端提示管用得多。

# 这类  # 这是  # 得多  # 盯着  # 重启  # 适用于  # 而非  # 浏览器  # 没了  # Error  # 堆  # 报错  # 栈  # function  # 行号  # var  # 前端  # php  # apache  # nginx  # 开发环境  # undefined  # php报错 

相关栏目： <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 AI推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 SEO优化<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 技术百科<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 谷歌推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 百度推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 网络营销<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 案例网站<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 精选文章<？ｍｕｍａ echo $count; ?> 】