PHP 中 error_get_last() 不会自动清空
调用 error_get_last() 只是读取当前最后一次错误，它不会重置或清除错误状态。后续即使没新错误，它仍返回上一次的残留结果。这是最常被误以为“已重置”的地方。
- 常见错误现象：
error_get_last()在try/catch后仍返回之前未处理的警告（如E_WARNING），导致逻辑误判 - 根本原因：PHP 错误机制本身没有“重置”接口，
error_get_last()是只读快照，不是状态机 - 正确做法：必须手动覆盖或丢弃该值——比如在关键检查前主动设为
null或重新触发一次无害操作
用 set_error_handler() 拦截后需手动管理状态
如果你用 set_error_handler() 捕获了错误，error_get_last() 依然可能保留旧值，因为自定义处理器不自动影响内部错误栈。
- 使用场景：想在函数内做“试探性执行 + 检查是否出错”，例如尝试
fopen()后立刻判断成败 - 参数差异：默认错误处理器下，
E_NOTICE和E_WARNING会写入error_get_last()；但若你用set_error_handler()并返回true，这些错误就不会进入最后错误记录 - 实操建议：在 handler 内部用静态变量或全局数组暂存错误，避免依赖
error_get_last() - 性能影响：频繁切换 error handler 开销小，但每次调用 handler 都有函数调用成本，不适合高频循环内使用
error_clear_last() 是 PHP 7.2+ 唯一真正“重置”手段
PHP 7.2 起才提供 error_clear_last()，它才是唯一能清空 error_get_last() 返回值的函数。低于该版本只能模拟。
- 兼容性注意：PHP 7.1 及更早版本调用会报
Fatal error: Uncaught Error: Call to undefined function error_clear_last() - 典型用法：
error_clear_last(); $result = @file_get_contents('/nonexistent'); if (error_get_last()) { // 这里进不来，因为上面已清空 } - 容易踩的坑：加了
@抑制符后，错误仍会写入error_get_last()，必须显式调用error_clear_last()才能确保干净
替代方案：别依赖全局错误状态
靠 error_get_last() 判断流程，本质上是把错误处理耦合进了业务逻辑，极易出错。更稳的方式是让函数自己返回明确信号。
立即学习“PHP免费学习笔记（深入）”；
- 常见错误现象：写了个封装函数调用
mysqli_query()，却在外部用error_get_last()判断成败——万一中间其他代码触发警告，就误判了 - 实操建议：
- 对可预测失败的操作（如文件、数据库、HTTP 请求），优先用返回值或异常控制流程
- 用
mysqli_errno()、curl_errno()等专用函数代替通用错误检查 - 如果真要“试探”，用
file_exists()先查路径，比@fopen()+error_get_last()更可靠
- 为什么难绕开：有些扩展（如某些 C 扩展）不抛异常也不返回错误码，只剩
error_get_last()这条路——这时候务必配好版本检测和 fallback
error_clear_last() 当成万能解药，却忘了它只清最后一次，且无法回溯历史错误。真要健壮，得从函数设计源头避开对全局错误状态的依赖。 
