在ThinkPHP 6.0项目中，当用户访问不存在的路由、数据库连接失败或控制器方法抛出未捕获的异常时，系统默认会展示调试信息或返回原始错误堆栈。这种做法既不安全也不友好——必须统一接管，并根据不同场景输出差异化响应，才能真正实现优雅的错误处理机制。
全局接管异常处理类
在 app/exception/ExceptionHandler.php 中创建一个自定义处理器，继承 think\exception\Handle，并重写 render 方法，以控制最终输出内容。关键点在于：类名必须命名为 ExceptionHandler，命名空间严格设定为 app\exception，否则配置将无法生效。
然后打开 config/app.php，找到 'exception_handle' 配置项，将其值修改为：app\exception\ExceptionHandler::class。这一步不可跳过——如果没有显式指定，框架会一直沿用默认处理器，导致所有自定义逻辑都不会触发。
区分请求类型返回格式
在 ExceptionHandler.php 的 render 方法中，首先判断请求是否为 AJAX 或 API 类型：使用 $request->isAjax() || $request->isJson() 判断；若为真，则构造标准 JSON 响应：return json(['code' => 0, 'message' => $e->getMessage()], 500);。非 JSON 请求则交由父类处理：return parent::render($request, $e);，以保持 HTML 异常页面的可用性。
需要特别注意：不要在非 JSON 分支里手动 echo 或 return 字符串，否则会破坏框架的响应生命周期，导致 headers already sent 错误。
按异常类型定制响应
方法一：HTTP 异常直接透传状态码
若抛出 think\exception\HttpException（例如 abort(404)），直接提取状态码：$statusCode = $e->getStatusCode();，再通过 response(file_get_contents(...), $statusCode) 渲染对应的 HTML 模板。
方法二：验证异常返回 422 状态码
当遇到 think\exception\ValidateException 时，立即返回 JSON 格式的错误详情：return json(['code' => 422, 'errors' => $e->getError()], 422);。
方法三：数据库异常降级为通用错误
捕获 think\db\exception\DataNotFoundException 或 PDOException 时，不要暴露表名、SQL 片段等敏感信息，统一返回 json(['code' => 500, 'message' => '服务暂时不可用'], 500)。
部署环境启用静态错误页
第一步：确认 config/app.php 中已开启部署模式：'app_debug' => false。
第二步：在 config/app.php 中添加配置块：
'http_exception_template' => [
404 => app()->getAppPath() . 'view/error/404.html',
500 => app()->getAppPath() . 'view/error/500.html',
403 => app()->getAppPath() . 'view/error/403.html',
],
第三步：在 app/view/error/ 目录下创建对应的 HTML 文件，内容可包含纯前端逻辑（如自动跳转首页），但禁止执行 PHP 代码或调用框架函数——该目录下的文件在部署模式中会被直接读取并输出，不经过模板引擎解析。
第四步：确保 Web 服务器（Nginx/Apache）已禁用对 .html 后缀的 PHP 解析，否则可能造成模板文件被当作 PHP 执行，引发安全风险。
API 模块独立异常处理
① 在 app/api/exception/ApiExceptionHandler.php 创建专用处理器，同样继承 think\exception\Handle。
② 编写 render 方法，强制所有异常返回 JSON，且固定 HTTP 状态码为 200（适配部分老旧前端对非2xx状态码的兼容问题）。
③ 修改 app/api/provider.php，添加服务绑定：'think\exception\Handle' => app\api\exception\ApiExceptionHandler::class。
④ 删除或注释掉全局 config/app.php 中的 'exception_handle' 配置——多应用模式下，模块级的 provider 绑定优先级高于全局配置，此处必须隔离，否则 API 模块仍会走全局处理器。
这一步是关键分水岭：不移除全局配置，API 模块的异常仍将被全局 ExceptionHandler 拦截，导致 JSON 响应逻辑失效。
