ThinkPHP版本演进中的异常处理机制对比_全局异常监控实施-ThinkPHP-PHP中文网

thinkphp 5.1 的 handle::render() 捕不到 http 异常，因其由 httpexception 自行响应，不走 render 流程；tp6 中 handle 改为接口且 render() 签名变更，需适配返回 response 并显式上报异常。

thinkphp版本演进中的异常处理机制对比_全局异常监控实施

ThinkPHP 5.1 的 `think\exception\Handle` 为什么捕不到 HTTP 异常？

因为 TP5.1 默认把 HttpException（比如 404、500）交给了 think\exception\HttpException 自行响应，不走全局 Handle::render() 流程。你重写了 render()，但发现 404 页面还是原样吐出来，没进你的日志或监控逻辑——就是这个原因。

真正能统一拦截所有异常的入口是 App::middleware() 中注册的全局中间件，或者更底层的 think\App::runWithRequest() 异常兜底
Handle::report() 倒是会触发（用于记录），但 render() 不负责 HTTP 异常渲染，它只处理非 HttpException 子类的异常
若想统一处理，要么在中间件里 try/catch 包裹 $next($request)，要么继承 Handle 并重写 render()，对 HttpException 实例手动接管响应

ThinkPHP 6.x 的 `think\exception\Handle` 接口变更与兼容陷阱

TP6 把 Handle 从类改成了接口 think\contract\ExceptionHandlerInterface，默认实现是 think\exception\Handle，但方法签名变了：render() 返回 Response 对象，不再接受 $request 参数；report() 也不再自动调用 Log::record()。

升级时如果沿用 TP5 的自定义 Handle 类，会直接报 Method render() must have exactly 1 parameter
TP6 的 render() 只接收 $e，响应构造必须自己 new Response 或调用 json()/view() 辅助方法
监控上报逻辑建议全挪到 report()，但要注意：TP6 默认不会在 report() 里记录日志，得显式调用 Log::record() 或集成 Sentry 客户端

全局异常监控接入 Sentry 的关键配置点（TP5.1 / TP6 共通）

不是加个 composer require sentry/sentry 和初始化 SDK 就完事。Sentry 要真正捕获框架层异常，必须在异常流出框架前完成上报。

TP5.1：在自定义 Handle::report() 里调用 Sentry\captureException($e)，别漏掉 return parent::report($e) 否则日志断掉
TP6：实现自己的 ExceptionHandler，在 report() 里上报，并确保该类被正确绑定到容器：$app->bind(\think\contract\ExceptionHandlerInterface::class, \app\exception\SentryHandler::class)
务必关闭 display_error 和 show_error_msg，否则敏感信息可能泄露到前端，且干扰 Sentry 的上下文采集

为什么 `try/catch` 里抛出的异常有时不进全局监控？

因为你在控制器或服务里写了 try { ... } catch (\Exception $e) { throw $e; } —— 这种“裸抛”会丢失原始异常堆栈，Sentry 捕获到的是新异常对象，trace 断层，cause 为空。

正确做法是 throw $e 前先调用 Sentry\captureException($e)，或直接 throw new \RuntimeException('xxx', 0, $e) 保留 previous
TP6 的 report() 方法默认不处理已捕获异常，只有未被捕获、冒泡到顶层的才会触发，所以业务层 catch 后不重新抛出 = 监控盲区
高频调用的工具函数（如 validate()、db()->transaction()）内部异常容易被框架静默吞掉，建议在这些位置加显式上报钩子