不该在控制器用try-catch包业务逻辑，除非明确需拦截并转换响应；TP6+默认全局异常处理已覆盖验证、HTTP等异常，手动捕获易导致日志丢失、状态码错乱、中间件中断。
ThinkPHP控制器里该不该用try-catch包业务逻辑
不该，除非你明确知道要拦截并转换成特定响应（比如把ValidateException转成400 JSON）。TP6+默认已启用全局异常处理，手动try-catch反而容易打断它，导致错误日志丢失、HTTP状态码错乱、中间件流程中断。
常见错误现象：
– 写了try-catch但没throw或没返回响应，页面空白
– 捕获后只echo或dump()，API接口返回HTML片段
– 忘记调用$this->error()或json()，结果返回500页面而非JSON
- 业务校验类异常（如验证失败、参数缺失）建议直接抛出
ValidateException或HttpException，由框架自动处理 - 需要自定义响应格式时，捕获后必须显式返回（如
return json(['code'=>400, 'msg'=>'xxx'], 400)） - 数据库操作异常（如
DbException）一般不建议在控制器捕获——应交由全局AppExceptionHandle统一记录和降级
app/exception/Handler.php里怎么改写全局异常响应
改这里才能真正控制所有未被捕获异常的输出格式。TP6默认会根据请求类型（AJAX/JSON/HTML）自动切换响应，但常被忽略的是render()方法中对Response对象的状态码和Header控制。
使用场景：
– 所有API接口统一返回{code, msg, data}结构
– 需要记录敏感异常到ELK但屏蔽堆栈给前端
– 第三方SDK抛出的非TP标准异常需兜底处理
立即学习“PHP免费学习笔记（深入）”；
- 不要直接
echo或die()，必须返回Response实例（如return response()->json([...], 500)） - 区分
$e instanceof HttpException和$e instanceof PDOException，前者可暴露$e->getStatusCode()，后者必须过滤敏感信息 - 调试阶段可加
if (app()->isDebug()) { $data['trace'] = $e->getTraceAsString(); }，上线前删掉
为什么validate()失败时不走全局异常处理器
因为validate()默认抛出ValidateException，而TP6的Handler.php里render()方法默认只接管HttpException及其子类，ValidateException继承自think\Exception，不在默认捕获链里。
参数差异：
– ValidateException含$this->error（字符串）和$this->rule（规则数组）
– HttpException含$this->statusCode和$this->headers
- 方案一：在
Handler::render()开头加判断：if ($e instanceof ValidateException) { return json(['code'=>400, 'msg'=>$e->getError()]); } - 方案二：改验证调用方式，用
$validate->batch()->check($data)配合ValidateException::getError()手动收集，避免抛异常 - 方案三：重写
Validate类，在failException构造时传new HttpException(400, $e->getError())
全局异常处理里最容易漏掉的兼容性点
TP6.1+启用了think\exception\Handle作为基类，但很多老项目还沿用think\exception\Handle的旧版签名，导致render()方法参数从(Request $request, Throwable $e)变成(Request $request, Exception $e)，PHP8.1+会报TypeError。
性能影响：
– 在render()里做DB查询或远程调用会导致所有异常响应变慢
– 多层catch嵌套（比如先捕获ValidateException再catch Exception）可能掩盖真实错误类型
- 确保
config/exception.php中ignore_exception没误配，否则某些异常会被静默吞掉 - Log写入前检查
app()->isDebug()，避免生产环境日志爆炸 - 如果用了Swoole，注意
Handler里的资源（如PDO连接）不能跨请求复用，得用Container::pull()重新获取
异常处理真正的复杂点不在写代码，而在分清「哪层该拦截」「哪层该透传」——控制器只管业务语义，框架层管协议规范，日志层管追溯闭环。少一层try-catch，就少一个状态失控的入口。
