全局异常处理器没生效？检查 app_exception 配置是否被覆盖
ThinkPHP 默认会读取 app_exception 配置项来决定用哪个类处理未捕获异常，但很多人在 app.php 里改了，却忘了中间件或命令行环境可能加载了另一份配置。常见现象是 HTTP 请求走自定义处理器，而 php think run 或单元测试里仍打印原生错误堆栈。
确认配置路径：必须在 config/app.php 中设置 ‘app_exception’ => ppcommonexceptionHandler::classCLI 环境下，think 命令默认不加载 app.php 的完整配置，需手动在命令入口调用 App::bind(‘think\exception\Handle’, ppcommonexceptionHandler::class)若用了多应用模式（APP_MULTI），每个应用的 app_exception 需单独配置，不能只写在根配置里
继承 thinkexceptionHandle 后，render() 方法返回内容被框架二次渲染
ThinkPHP 5.1+ 对 render() 返回值做了强约束：必须返回 Response 实例，否则会被自动包装成 HTML 页面——哪怕你已输出 JSON 错误结构，最后仍混入一堆框架样式和 footer。
render() 内不要直接 echo 或 exit，必须 return 一个 response() 调用结果API 场景下，统一用 return json([‘code’ => -1, ‘msg’ => $e->getMessage()], 500)，别依赖 $e->getStatusCode()，它常为 0想复用原有模板（如 404 页面），得显式调用 view() 并确保返回的是 Response 对象：return response($this->view->fetch(‘error/500’), 500)->contentType(‘text/html’);
report() 方法里记录日志，但 $e->getTraceAsString() 太长撑爆数据库字段
默认日志写入用的是 thinklogdriverFile，但若把完整 trace 存进 MySQL 的 TEXT 字段，超长时会静默截断，查问题时发现“关键堆栈没了”。
精简 trace：用 array_slice($e->getTrace(), 0, 10) 控制深度，再 json_encode 存储敏感信息过滤：避免把 $_POST、$_SERVER[‘HTTP_AUTHORIZATION’] 直接打日志，可在 report() 开头加判断：if (strpos($e->getMessage(), ‘SQLSTATE’) !== false) { … }异步记录更稳妥：用 Log::channel(‘daily’)->error(…) 替代直接写文件，避免阻塞主流程
自定义异常类抛出后，render() 拿不到原始类型，全被转成 HttpException
这是 ThinkPHP 的隐式转换逻辑：只要异常继承自 thinkException 或含 httpCode 属性，框架就会在捕获前把它包装成 HttpException，导致你在 render() 里用 instanceof 判断失败。
立即学习“PHP免费学习笔记（深入）”；
不要靠 get_class($e) 匹配自定义类名，改用 $e->getPrevious() 往回找原始异常推荐方案：所有业务异常统一继承 thinkexceptionHttpException，并设好 $statusCode 和 $headers，这样既兼容框架逻辑，又保留语义若必须区分类型，可在构造时传标识：throw new UserException(‘xxx’, [‘type’ => ‘user_login_fail’])，然后在 render() 中解析 $e->getData()[‘type’]实际项目里最常漏掉的是 CLI 环境的异常接管，以及 trace 日志的长度控制——这两处不提前压测，上线后要么命令执行无声失败，要么日志表被撑爆锁死。
评论(0)