最常见的原因是缓存未清或容器绑定未到位：Handler.php须继承think\ExceptionHandler，并在app/provider.php中绑定到think\exception\Handle接口；runtime/cache/与runtime/container/需清除，多应用、CLI环境需单独配置，render()返回值必须为think\Response实例，report()需脱敏trace并异步记录。
app/exception/Handler.php 为什么没生效
最常见的原因是缓存没清或绑定没到位。ThinkPHP 不靠配置开关触发异常处理器，而是靠容器绑定——app/exception/Handler.php 必须继承 think\ExceptionHandler，且在 app/provider.php 中显式绑定到 think\exception\Handle 接口。
以下情况会导致它“看起来没用”：
-
runtime/cache/和runtime/container/没清，旧绑定仍被加载 - 删过默认
Handler.php后重装框架，文件缺失，请求直接抛原始 PHP 错误 - 用了多应用模式（
APP_MULTI = true），但只在根config/app.php配了app_exception，子应用未单独配置 - CLI 环境（如
php think run）下，app.php的配置默认不加载，需在命令入口手动调用App::bind('think\exception\Handle', \app\exception\Handler::class)
render() 返回值类型错会导致响应混入框架页脚
ThinkPHP 5.1+ 对 render() 的返回值做了强校验：必须是 think\Response 或其子类实例。返回数组、字符串甚至 json() 的裸结果都不行——框架会自动把它包装成 HTML 页面，最终响应里夹带默认错误页的 footer 和样式。
正确写法只有两种典型场景：
立即学习“PHP免费学习笔记（深入）”；
- API 响应：
return json(['code' => -1, 'msg' => $e->getMessage()], 500); - HTML 页面：
return response($this->view->fetch('error/500'), 500)->contentType('text/html');
别依赖 $e->getStatusCode()，普通 Exception 调这个方法返回 0，HTTP 状态码就变成 200；也别在 render() 里 echo 或 exit，否则响应体可能被截断。
report() 写日志时 trace 太长或泄露敏感字段
report() 是记录异常的地方，但默认用 $e->getTraceAsString() 直接入库或写文件，极易撑爆数据库 TEXT 字段，或泄露 $_POST、$_SERVER['HTTP_AUTHORIZATION'] 等敏感信息。
实操建议：
- 控制堆栈深度：
$trace = array_slice($e->getTrace(), 0, 10);，再json_encode($trace)存储 - 按异常类型做脱敏判断：比如
if (strpos($e->getMessage(), 'SQLSTATE') !== false)，则过滤$_POST和$_GET - 异步记录更稳妥：
Log::channel('daily')->error(...)，避免阻塞主流程
404 和 500 怎么统一走自定义页面
ThinkPHP 默认把 HttpException（含 404/500）和普通 Exception 分开处理，但你可以在 render() 里统一接管：
-
HttpException子类（如think\exception\HttpException）可调$e->getStatusCode()拿真实状态码 - 普通
Exception默认映射为 500，但你可以主动throw new HttpException(404, 'Not Found')来强制跳转 - 别在
render()里直接view('error/404')，要确保返回的是Response实例，例如：return view('error/404')->code(404);
真正容易被忽略的是：开发环境和生产环境都走同一套 render() 逻辑，app_debug 只影响是否显示详细错误页，不影响处理器是否执行。所以模板里别写 PHP 逻辑，静态 HTML + CSS 最安全。
