仅靠 set_error_handler() 无法屏蔽错误输出，必须同时禁用 display_errors、合理设置 error_reporting、在回调中不输出且返回 true，并用 register_shutdown_function() 捕获致命错误。
PHP自定义错误处理器如何屏蔽错误输出
直接说结论：仅靠 set_error_handler() 无法真正“屏蔽”错误显示，它只接管错误处理逻辑，但不会阻止 PHP 将错误信息输出到页面或日志——除非你同时禁用 display_errors 并确保不 echo/print 错误内容。
为什么 set_error_handler 不等于隐藏错误
常见误解是注册了自定义处理器就“看不见错误了”，实际它只是把错误交给你处理，而默认行为（如 E_WARNING 仍会打印到浏览器）依然存在，尤其当 error_reporting 未调低、display_errors 开启时。
-
set_error_handler()返回true表示已处理，PHP 不再触发默认错误报告 —— 但前提是该错误类型未被error_reporting()屏蔽 - 若函数内主动
echo $message或trigger_error()，错误反而更显眼 - Fatal error（如
ParseError、Fatal error: Call to undefined function）根本不会进set_error_handler()，必须用register_shutdown_function()+error_get_last()捕获
真正兼隐错的组合操作
要让错误既不显示又不报错（即“兼隐错”），需三层配合：
- 运行前关闭输出：
ini_set('display_errors', '0');（线上环境应设为Off） - 按需过滤错误级别：
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED); - 在
set_error_handler()回调中不做任何输出，且返回true；对致命错误补漏：register_shutdown_function(function () { if ($e = error_get_last()) { if (in_array($e['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])) { // 记日志，不输出 error_log("Fatal: {$e['message']} in {$e['file']}:{$e['line']}"); } } });
容易被忽略的兼容性坑
PHP 8.0+ 对错误处理更严格，部分旧写法会失效：
立即学习“PHP免费学习笔记（深入）”；
-
set_error_handler()不再捕获E_WARNING级别的类型错误（如传 string 给 int 参数），这类会抛TypeError异常，需用set_exception_handler() - 自定义处理器中若调用
debug_backtrace()过深，可能引发内存问题，建议限制 depth：debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 5) - CLI 模式下
display_errors默认为Off，但 Web SAPI（如 Apache mod_php）默认为On，配置不可依赖环境默认值
真正难的不是写 handler，而是厘清 error / exception / fatal 的分界，以及每个 SAPI 下 ini 设置的实际生效点。
