thinkphp 8.0 全局异常捕获默认不生效，主因是配置位置错误（必须在 config/app.php 中设置 app_exception）、cli 环境未手动绑定异常处理器、或 render() 未返回 think\response 实例。
ThinkPHP 8.0 的全局异常捕获默认不生效，不是代码写错了，而是配置位置、环境适配或返回值类型三处任一出错——你看到空白页或原生堆栈，基本就卡在这三点上。
app_exception 配置必须写在 config/app.php 里
TP8 不再自动加载 app/exception.php，只认 config/app.php 中的 'app_exception' 配置项。常见错误是：你在 Web 环境下改了这个文件，但跑 php think run 或单元测试时，命令行入口根本没读它。
- 确认
'app_exception' => \app\exception\ExceptionHandle::class出现在config/app.php的return []数组中 - 多应用模式下（
APP_MULTI = true），每个子应用的config/app.php都得单独配，根目录的配置无效 - CLI 场景下需手动绑定：
App::bind('think\exception\Handle', \app\exception\ExceptionHandle::class)，加在think命令入口文件顶部
render() 必须返回 think\Response 实例
TP8 对 render() 返回值做了强校验：如果不是 think\Response 实例，框架会二次包装成 HTML 页面——哪怕你写了 return json([])，最终响应体里也会混入框架 footer 和样式。
- API 请求请明确返回：
return json(['code' => -1, 'msg' => $e->getMessage()], 500) - Web 页面请求请显式构造：
return response($this->view->fetch('error/500'), 500)->contentType('text/html') - 绝对不要在
render()里echo、exit或直接return []—— 这些都会触发二次渲染 -
$e->getStatusCode()在多数自定义异常中为 0，别依赖它；HTTP 状态码应由你显式传入
report() 要精简 trace 并过滤敏感字段
默认 report() 调用父类逻辑，但 $e->getTraceAsString() 动辄上万字符，MySQL TEXT 字段截断、日志文件暴涨、甚至阻塞主线程。
- 精简堆栈深度：
$trace = array_slice($e->getTrace(), 0, 8)，再json_encode($trace) - 过滤敏感上下文：检查
$e instanceof \think\db\exception\DataNotFoundException或含'SQLSTATE'时，跳过$_POST、$_SERVER['HTTP_AUTHORIZATION']等字段 - 异步写日志更稳：
Log::channel('daily')->error(...)替代直接写文件，避免阻塞主流程
中间件层要补上 UniformJsonResponse
ExceptionHandler::render() 仅在生命周期末尾触发，无法拦截验证失败（ValidateException）、路由未匹配（RouteNotFoundException）等框架级异常——这些在到达处理器前，已被其他中间件提前输出原始格式。
- 新建中间件：
php think make:middleware UniformJsonResponse - 在
handle()中强制统一封装：if ($response instanceof \think\Response && !($response instanceof \think\response\Json)) { ... return json($wrapped, 500); } - 注册为全局中间件，并确保它排在
\think\middleware\ResponseTrace::class之后、缓存中间件之前
最易被忽略的是：CLI 环境和中间件顺序。很多人调通了 HTTP 请求，一跑命令行任务就崩回原生堆栈；或者把 UniformJsonResponse 放太靠前，结果连正常 JSON 响应都被重包了一次。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
