error_get_last 只能捕获最近一次错误，且仅限运行时错误
error_get_last 不是全局错误监听器，它只是读取 PHP 内部维护的一个“最后错误快照”。这个快照只在发生 E_ERROR、E_WARNING、E_NOTICE 等运行时错误后被更新，而且一旦下一次错误发生，前一次就彻底覆盖了。
常见错误现象：error_get_last() 返回 null，不是因为没出错，而是因为你调用它太晚了——比如在 try/catch 之后、或在错误触发后又执行了其他可能出错的语句（哪怕只是 echo），都可能导致快照被刷新或清空。
- 必须紧接在疑似出错的代码之后立即调用，中间不能夹杂其他可能触发错误的操作
- 它对语法错误（
Parse error）、致命错误（Fatal error导致脚本终止）无效——这些错误发生时，脚本已退出或未进入可执行阶段，error_get_last根本没机会运行 - 在 CLI 模式下行为一致，但 Web SAPI（如 Apache、FPM）中要注意输出缓冲和错误报告级别影响可见性
配合 error\_reporting 和 @ 抑制符才能稳定捕获预期错误
默认情况下，E_NOTICE 或 E_USER_NOTICE 可能不显示也不写入日志，导致你以为“没报错”，其实 error_get_last 已记录但你看不见。关键是要主动控制错误级别，并小心使用抑制符。
使用场景：你想静默处理一个可能失败的文件操作，然后根据错误类型做不同响应，而不是让错误直接抛到页面上。
立即学习“PHP免费学习笔记（深入）”；
- 先用
error_reporting(E_ALL)确保所有错误都参与快照更新（注意：这不会改变是否显示，只影响是否记录） - 对目标语句加
@抑制其直接输出，否则错误信息会提前刷到输出缓冲，干扰后续逻辑 - 紧接着调用
error_get_last()，并判断['type']字段是否为期望的错误类型（如E_WARNING）
示例：
error_reporting(E_ALL);
@file_get_contents('/nonexistent.txt');
$last = error_get_last();
if ($last && $last['type'] === E_WARNING) {
echo "文件读取失败：{$last['message']}";
}
error\_get\_last 在 require/include 失败时不可靠
当 require 或 include 加载失败（如文件不存在、权限不足），PHP 会触发 E_COMPILE_ERROR 或 E_WARNING，但具体行为取决于上下文：如果是在顶层作用域失败，脚本通常直接终止；如果在函数内，部分版本可能仍留有快照，但不可依赖。
更糟的是，require_once 的重复包含失败会返回 E_NOTICE，而 include 失败返回 E_WARNING，类型不统一，用 error_get_last 做分支容易漏判。
- 不要用
error_get_last判断require是否成功——改用file_exists()+is_readable()预检，或捕获Exception（如果封装在__autoload或 Composer autoloader 中） - 若必须动态加载，优先选
include并检查返回值（false表示失败），再辅以error_get_last分析原因 - 在 PHP 8.0+ 中，
require失败会抛Error异常，此时应改用try/catch，error_get_last完全失效
替代方案比死磕 error\_get\_last 更实用
真正需要“捕获最后错误”的场景，往往说明你在补救一个本该被预防或结构化处理的问题。与其反复调试 error_get_last 的时序和类型边界，不如换更稳的方式。
- 对函数调用，优先查文档看是否返回
false或null，比如fopen()、json_decode()、mysqli_query()都有明确失败返回值 - 对用户级错误，用
trigger_error()+ 自定义错误处理器（set_error_handler()），把错误收口到可控逻辑里 - 现代项目中，用
try/catch包裹throw new Exception()或throw new Error()是主流，error_get_last基本只用于遗留系统兜底或调试临时打点
它是个窄口径工具，用对了省事，用错了反而掩盖问题本质——尤其是当错误发生在你没监控到的 include 链、或被其他扩展重置了错误状态时，快照早就空了。
