PHP错误处理：set_error_handler与异常捕获

理解PHP错误与异常的处理边界

在PHP中，错误（Error）与异常（Exception）属于两套不同的机制。传统错误如E_WARNING、E_NOTICE、E_DEPRECATED等属于运行时警告或提示，通常不会中断脚本执行；而E_ERROR等致命错误会直接终止程序。自PHP 7起，多数致命错误被重构为实现了Throwable接口的Error对象，从而支持面向对象捕获。Exception则是开发者主动throw的业务逻辑异常。set_error_handler仅能接管可恢复的运行时错误，无法拦截语法解析错误（E_PARSE）或编译期错误，也不能替代try-catch对主动抛出异常的捕获。明确这一边界后，才能合理划分“底层运行时拦截”与“业务层异常流转”的职责，为构建统一处理流程奠定基础。

使用set_error_handler自定义错误处理

set_error_handler函数允许开发者注册自定义回调，接管PHP默认的错误输出行为。其基本语法为set_error_handler(callable $callback, int $error_types = E_ALL)。回调函数需接收五个参数：错误级别、错误信息、触发文件、行号及上下文变量。在回调内部，可通过error_log将错误写入系统日志，或将其包装为ErrorException并重新抛出，以便交由后续异常机制处理。需注意回调的返回值：若返回true，则PHP将跳过默认错误处理；若返回false或null，则继续执行内置处理器。实际开发中，建议仅针对E_WARNING、E_NOTICE等可恢复级别进行接管，避免过度拦截导致底层致命错误被掩盖。

使用try-catch捕获并处理异常

try-catch-finally是PHP处理异常的标准结构。在try块中执行可能抛出异常的代码，catch块按类型顺序捕获Exception或Throwable对象。PHP 7之后推荐优先捕获Throwable以兼容Error与Exception。在catch块中，应记录完整堆栈信息至日志系统，并向用户返回脱敏后的安全提示，严禁直接将$e->getTraceAsString()输出至前端，以防泄露敏感路径或数据库结构。finally块无论是否发生异常都会执行，常用于释放资源或关闭连接。通过分层捕获与统一日志记录，既能保障系统稳定性，又能满足生产环境的安全合规要求。

组合错误处理与异常机制并验证结果

将set_error_handler与try-catch结合，可构建全链路错误处理方案。典型做法是在入口文件注册错误处理器，将捕获的运行时错误转换为ErrorException并抛出，随后由全局try-catch或框架异常中间件统一接管。验证时需分别触发E_NOTICE、E_WARNING及主动throw Exception，观察日志记录与页面响应是否符合预期。常见避坑点包括：E_ERROR与E_PARSE无法被set_error_handler拦截，需依赖PHP配置或前置语法检查；生产环境必须设置display_errors=Off与log_errors=On，防止错误信息暴露；日志记录应区分级别并采用异步写入，避免阻塞主流程。通过严格测试与配置隔离，可建立高可用的错误处理机制。