error_get_last() 是 php 中唯一能安全获取最近一次运行时错误的函数，返回含 type、message、file、line 的数组，未出错时返回 null；它不记录历史、不捕获被抑制或低级别未触发错误，且对语法错误无效。
PHP如何获取上一条错误（error_get_last()）
PHP没有全局错误栈，error_get_last() 是唯一能安全读取「最近一次运行时错误」的内置函数。它返回一个关联数组，包含 type、message、file、line 四个键，仅在发生错误后调用才有效——如果之前没出错，返回 null。
常见误用是把它当「错误日志读取器」反复调用，其实它不记录历史，只抓最后一次；也不捕获 E_NOTICE 以下级别（如未定义变量警告），除非已开启 error_reporting(E_ALL) 且该警告实际被触发。
- 必须在错误发生后「立即」调用，中间穿插任何 PHP 执行（包括
echo、函数调用）都可能被后续内部错误覆盖 - 对
parse error（语法错误）无效——脚本根本不会执行到error_get_last()这行 - 在
try/catch中无法捕获普通错误（如E_WARNING），仍需靠它配合set_error_handler()拦截
为什么 error_get_last() 经常返回 null
不是函数坏了，而是它严格依赖「错误是否真的发生并进入 PHP 错误处理流程」。比如：
-
file_get_contents('/nonexistent.txt')默认只触发警告（E_WARNING），若error_reporting关闭了该级别，就不会留下痕迹 - 函数调用失败但被
@抑制符屏蔽（如@file_get_contents(...)），错误不会进入处理流程，error_get_last()无从得知 - CLI 模式下某些 SAPI 层错误（如内存耗尽）可能由底层直接终止，不经过 PHP 错误处理器
验证方法：先确保 error_reporting(E_ALL); ini_set('display_errors', '1'); 开启，再触发一个明确错误（如 call_user_func(null)），紧接着调用 error_get_last() —— 这时大概率拿到结果。
替代方案：用 set_error_handler() 主动捕获
如果需要稳定捕获所有可拦截错误（E_WARNING、E_NOTICE 等），不能只靠事后查 error_get_last()，得提前注册处理器：
set_error_handler(function($level, $message, $file, $line) {
if (!(error_reporting() & $level)) {
return false; // 遵守当前 error_reporting 设置
}
// 记录或处理 $message
error_log("[$level] $message in $file:$line");
});
注意：set_error_handler() 对 E_ERROR、E_PARSE、E_CORE_ERROR 等致命错误无效，这类错误会直接中断脚本；它也无法捕获异常（Exception），那是 set_exception_handler() 的职责。
- 注册后，所有非致命错误都会进这个回调，比轮询
error_get_last()更可靠 - 务必检查
error_reporting() & $level，否则会绕过 php.ini 或ini_set()的错误级别控制 - 回调中不要再触发新错误（比如调用不存在的函数），否则可能造成无限递归
调试时容易忽略的关键点
开发中常以为「看到报错就等于能拿到错误信息」，但实际有三个隐形断层：
- Web 服务器（如 Nginx）可能截断 PHP 错误输出，导致浏览器看不到
display_errors内容，但error_get_last()仍可用 —— 此时应查 PHP 错误日志路径（ini_get('error_log')） -
error_get_last()返回的file和line指的是错误发生的源头，不是调用它的位置，别误当成调试断点 - 在 Composer 自动加载失败等场景，错误可能发生在
__autoload或spl_autoload_call内部，error_get_last()能取到，但堆栈信息极简，需配合debug_backtrace()补全上下文
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
