ThinkPHP异常处理安全关键在render()必须返回Response实例、report()需过滤敏感信息、生产环境须裁剪trace；APP_DEBUG=false不自动脱敏，404需Route::miss()单独处理，API响应应优先用expectsJson()而非isAjax()。
ThinkPHP 的异常信息处理不是“关掉调试模式就自动安全”，关键在 render() 方法是否真正接管了输出、report() 是否过滤了敏感字段、以及线上环境是否仍会把 trace 打进响应体里。
render() 返回非 Response 实例会导致框架二次包装
很多自定义异常处理器写了 return json(...) 或直接 echo，结果页面还是出现 ThinkPHP 默认的带堆栈的 HTML 错误页——这是因为 ThinkPHP 6.0+ 强制要求 render() 必须返回 \think\Response 实例，否则框架会自动把它包进一个 Response::create() 里，再套上默认样式和 footer。
- 正确写法是：
return response()->json(['code' => 500, 'msg' => '服务异常'], 500); - 想复用 HTML 模板？必须显式调用
view()并确保返回Response：return response($this->view->fetch('error/500'), 500)->contentType('text/html'); - 别在
render()里用exit或die，会跳过中间件和响应生命周期
APP_DEBUG=false 不等于异常信息脱敏
关掉 APP_DEBUG 只是隐藏调试页面，但如果你的 render() 方法里没做裁剪，$e->getTraceAsString() 依然可能出现在 JSON 响应的 msg 或日志中，尤其当异常来自数据库或验证器时，SQL 片段、文件路径、POST 参数都可能泄露。
- 生产环境的
render()应该对$e->getMessage()和$e->getTrace()做白名单过滤，例如只保留前 5 层 trace：array_slice($e->getTrace(), 0, 5) - 检查
config/app.php中'show_error_msg' => false是否存在（TP6.1+ 支持），旧版本需手动判断环境：if (app()->isProduction()) { ... } - 避免在
render()中调用dump()、var_export()等调试函数，它们可能触发额外输出
report() 写日志时 trace 太长会静默截断
用 Log::write() 或 MySQL 日志驱动存完整 getTraceAsString()，很容易超出 TEXT 字段长度，导致关键堆栈丢失，查问题时只能看到“...”结尾。
立即学习“PHP免费学习笔记（深入）”；
- 精简 trace：用
array_slice($e->getTrace(), 0, 10)控制深度，再json_encode()存储 - 过滤敏感上下文：检查
$_POST、$_SERVER['HTTP_AUTHORIZATION']、数据库连接配置等，不要原样打日志 - 异步记录更可靠：
Log::channel('daily')->error(...)比同步写文件更少阻塞主流程
404 不走 exception_handle，得靠 Route::miss()
很多人改了 exception_handle 类，却发现 404 请求根本没进 render()——因为 404 是路由未匹配的结果，不是 PHP 异常，它不触发异常处理器，只走路由系统的兜底逻辑。
- 必须在
route/app.php最底部加：Route::miss(function () { return response(view('public/404'), 404); }); - 确保
config/app.php中'url_route_must' => true已启用，否则通配路由可能提前吞掉所有请求 - Nginx 部署时注意别配
error_page 404，否则 PHP 层根本收不到 404 请求
最易被忽略的是：API 异常响应格式依赖 $request->expectsJson() 而非 isAjax()，现代前端 fetch 默认不带 X-Requested-With 头，只靠 isAjax() 判断会 fallback 到 HTML；还有就是多应用模式下，每个子应用的 exception_handle 都要单独配，根配置不会继承。
