PHP 错误处理统一化：异常、Error 与日志边界

PHP 错误处理统一化的关键，不是把所有问题都塞进一个 catch，而是先分清两条通道：能被抛出并实现 Throwable 的异常对象，和带有 E_WARNING、E_NOTICE 等级别的诊断错误。前者适合由业务代码决定是否恢复，后者适合在入口统一记录或按规则转换。生产环境还要关闭详细错误显示，避免路径、SQL 或配置内容随着响应泄露。

官方地址：https://www.php.net/manual/zh/language.error-handling.php

先把 Exception、Error 和诊断错误分到正确的通道

PHP 7 之后，许多程序性问题会以 Error 层次抛出；Exception 则更多承载可预期的业务或运行时异常。它们都实现 Throwable，所以统一兜底时应捕获 Throwable，但业务层不应因此把所有错误都当成可恢复故障。

因此，catch (Exception $e) 不能覆盖 TypeError。入口可以用 Throwable 统一兜底，但恢复动作仍应由具体业务边界决定。

在入口注册两类处理器，并保留可定位字段

把注册动作放在框架 bootstrap 或应用入口，避免每个控制器各写一套。下面的示例只演示边界：日志函数负责记录，响应层只返回公开的错误标识；真实项目可把 write_log() 替换成已有日志组件。

getMessage(),
        $error->getFile(),
        $error->getLine()
    ));

    // 生产响应只暴露可关联日志的编号，避免泄露内部实现细节。
    http_response_code(500);
    echo json_encode(['error' => 'internal_error', 'trace_id' => $traceId]);
});

// 只把当前 error_reporting 掩码内的诊断错误升级为异常。
set_error_handler(function (int $severity, string $message, string $file, int $line): bool {
    if (!(error_reporting() & $severity)) {
        // 未被当前掩码要求处理时，交还给 PHP 默认处理器。
        return false;
    }
    throw new ErrorException($message, 0, $severity, $file, $line);
});

这里有两个容易忽略的点。第一，set_error_handler() 回调返回后，脚本默认会从触发错误的下一行继续执行，所以需要转换或显式终止，不能只打印一行日志。第二，E_ERROR、E_PARSE、E_CORE_ERROR、E_COMPILE_ERROR 等并不由用户错误处理器覆盖，不能把它当成全能保险。

日志记录和 HTTP 响应要明确分层

统一处理器适合做三件事：记录异常类型和位置、补充请求关联标识、选择安全的响应状态。不要把请求体、Cookie、数据库密码或完整授权头直接拼进日志；也不要在异常处理器里再次抛出异常，否则可能失去原始故障。error_log() 的默认类型会写入 PHP 系统日志，也可以按部署配置写入指定文件，具体位置由 error_log 配置决定。

开发环境可以保留 E_ALL 并打开详细输出帮助定位；生产环境通常关闭 display_errors，打开 log_errors，让日志系统集中采集。是否记录完整堆栈，应由日志权限和保留策略决定，而不是直接输出到浏览器。

用一组最小检查验证边界是否生效

1. 主动抛出一个业务 RuntimeException，确认局部 try/catch 能转成业务错误，未捕获时才进入全局处理器。
2. 用 trigger_error('deprecated input', E_USER_WARNING) 验证回调是否收到 severity、文件和行号。
3. 触发一次 TypeError，确认捕获类型是 Throwable，而不是只写 Exception。
4. 检查 HTTP 响应不含绝对路径、堆栈和配置值，再到受控日志中用 trace_id 找到完整记录。

getSeverity() === E_USER_WARNING);
}

常见问题

为什么统一捕获 Throwable 仍不能继续执行？

因为它同时包含程序性错误。统一捕获的作用是记录和收口响应，不代表当前状态可以安全恢复。

set_error_handler 是否能接住所有 PHP 致命错误？

不能。官方手册明确列出的编译、解析和核心错误不在用户处理器覆盖范围内，仍要依赖 PHP 配置、进程监控和日志。

回调返回 false 有什么作用？

它会把当前诊断错误交还给 PHP 默认错误处理器；只有在你确认不需要自定义处理时才这样做。

一套可维护的 PHP 错误处理，边界应落在入口、业务层和日志系统之间：业务层决定能否恢复，入口负责兜底，配置控制是否显示，日志负责留下可关联证据。这样既不会漏掉 Error，也不会把生产细节直接暴露给用户。