thinkphp6+异常处理需避免盲目try-catch，全局handler已默认启用；\_validateexception须用全限定名捕获，render()必须返回response实例，cli/多应用下app_exception需单独配置，自定义异常可能被隐式转换。
ThinkPHP 的异常不能靠「写个 try-catch 就完事」来兜底，尤其在 TP6+ 中，全局异常处理已默认启用，手动捕获反而容易打断流程、丢日志、错状态码。
为什么 catch (ValidateException $e) 总是不生效
因为上传验证失败时抛出的不是 ValidateException，而是带下划线的 _ValidateException，它位于 think\exception 命名空间下，且类名开头必须保留反斜杠和下划线。
- 正确写法是：
catch (\think\exception\_ValidateException $e) - 错误写法包括：
catch (ValidateException $e)、catch (_ValidateException $e)、catch (\_ValidateException $e) - 这个类不会进入标准异常处理流程的
render()方法——它常被验证器或中间件提前“吞掉”，所以指望全局 Handler 统一接管上传校验失败，大概率拿不到原始字段名和文件名 - 若同时要处理移动失败等系统级错误，建议一起捕获
\think\exception\FileException
全局异常处理类 render() 返回内容被二次包装
TP6+ 要求 render() 方法必须返回 Response 实例，否则框架会自动把它包进 HTML 模板里，哪怕你写了 return json(...)，最后也可能混入一堆样式和 footer。
- API 场景下，务必用：
return json(['code' => -1, 'msg' => $e->getMessage()], 500) - 不要直接
echo或exit，这会导致响应中断、中间件失效 - 想复用 500 页面？得显式调用：
return response($this->view->fetch('error/500'), 500)->contentType('text/html') -
$e->getStatusCode()多数时候是 0，别依赖它设 HTTP 状态码
app_exception 配置在 CLI 和多应用下容易失效
很多人只改了 config/app.php 里的 app_exception，结果 php think run 或单元测试里还是打印原生堆栈——因为命令行环境默认不加载完整配置。
- 确认配置路径：必须在
config/app.php中设置'app_exception' => \app\common\exception\Handler::class - CLI 下需手动绑定：
App::bind('think\exception\Handle', \app\common\exception\Handler::class) - 多应用模式（
APP_MULTI = true）时，每个子应用的app_exception都要单独配，根配置不继承 - 自定义异常类抛出后，
render()里用instanceof判断常失败——TP 会在捕获前隐式转成HttpException
控制器里该不该写 try-catch
绝大多数情况不该。TP6+ 默认全局异常处理已覆盖验证、路由、HTTP 等常见异常，你在控制器里加一层 try-catch，反而容易导致三件事：日志没记全、状态码发错、中间件链断掉。
- 只有明确需要转换响应格式时才捕获，比如把
_ValidateException转成 400 JSON，并立即return json(..., 400) - 写了
try-catch却没return或throw，页面就空白；只dump()或echo，API 接口就返回 HTML 片段 -
_ValidateException有$e->getError()和$e->getRule()可用，HttpException有$e->statusCode，别绕路查属性
最易被忽略的一点：异常堆栈太长会撑爆数据库字段，report() 里用 array_slice($e->getTrace(), 0, 10) 控制深度，再存日志；敏感字段如 $_SERVER['HTTP_AUTHORIZATION'] 别直接打进去。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
