如何优化PHP项目的错误处理流程？利用观察者模式实现多渠道错误告警-php教程-PHP中文网

因为set_error_handler仅捕获E_WARNING等可恢复错误，对Exception、Error（如FatalError）完全无效；PHP 7+需协同set_exception_handler和register_shutdown_function三者兜底，且告警逻辑硬编码导致扩展难、耦合高。

如何优化php项目的错误处理流程？利用观察者模式实现多渠道错误告警

为什么直接用 `set_error_handler` 不够用

它只能捕获传统错误（E_WARNING、E_NOTICE 等），对 Exception 和 Error（如 FatalError）完全无效。PHP 7+ 的 Throwable 体系把错误和异常统一为可捕获对象，但 set_error_handler 还是老一套——你得额外配 set_exception_handler 和 register_shutdown_function 捕获致命错误，三套逻辑并行，容易漏掉某类问题。

更麻烦的是：所有告警逻辑（发邮件、推 Slack、写日志）都挤在同一个回调函数里，一改全动，加个新渠道就得改主流程，违反开闭原则。

只靠 set_error_handler 会漏掉未捕获的 Exception 和 FatalError
所有通知逻辑硬编码，新增钉钉告警要改核心函数，易出错
无法按错误类型分流：比如 E_ERROR 立刻电话告警，E_DEPRECATED 只进日报表

`Observer` 接口怎么对接 `Throwable`

观察者模式的关键是“被观察者”能统一发出通知，而 PHP 的错误/异常入口分散。你需要一个中心化的“错误事件分发器”，它不处理具体逻辑，只负责把 Throwable 实例广播给所有注册的观察者。

这个分发器本身不是 Observer，而是 Observerd（被观察者）。它需在三个地方注册钩子：

set_exception_handler：捕获所有未 catch 的 Exception/Error
set_error_handler：把传统错误包装成 Error 子类再抛出（例如 ErrorException）
register_shutdown_function：检查 error_get_last()，若存在 FatalError 就构造 FatalError 对象并通知

这样，所有错误最终都变成 Throwable 实例，进入同一通知管道。

邮件、Slack、Sentry 观察者怎么写才不耦合

每个观察者只关心“自己该做什么”，不依赖其他观察者，也不修改原始错误对象。接口定义只需一个 update(Throwable $e) 方法。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

示例：Slack 观察者只做三件事——格式化消息、调用 Slack webhook、记录发送状态。它不关心这错误是否也发了邮件，也不管 Sentry 是否已上报。

邮件观察者：mail() 或 SwiftMailer 发送，附带 $e->getTraceAsString()
Slack 观察者：用 curl POST 到 webhook URL，body 包含 $e->getMessage() 和环境标识（如 $_SERVER['APP_ENV']）
Sentry 观察者：调用 Sentry\captureException($e)，不自行重试或降级

关键点：所有观察者构造时接收配置（如 webhook 地址、邮箱列表），而不是从全局变量读取——方便单元测试和多环境切换。