tp6自定义异常处理器必须继承think\exception\handle并重写render()方法，返回\think\response实例；注册时需在app/provider.php中用完整命名空间绑定；render()仅处理响应，report()负责日志记录。
必须重写 render() 方法并注册到容器，否则任何模板、配置或抛出动作都无效。
自定义异常类必须继承 think\exception\Handle 并重写 render()
TP6 的错误处理入口不是视图路径或配置项，而是 render() 方法的返回值。它必须返回一个 \think\Response 实例，不能是字符串、数组或直接 echo。
- 不继承
think\exception\Handle→ 容器无法识别，注册后也不生效 - 没重写
render()→ 框架仍走默认逻辑，白屏或调试堆栈照常出现 - 返回
view('error/404')而不包response()→ 浏览器收到无状态码、无 Content-Type 的响应，表现为空白页或文件下载 - 漏掉
->code(404)→ 即使内容正确，HTTP 状态码仍是 200，前端无法靠 status 判断错误类型
provider.php 中绑定必须用完整命名空间路径
在 app/provider.php 中注册异常处理器时，键名固定为 'think\exception\Handle'，值必须是带反斜杠的绝对类名，且类文件需真实存在。
- 写成
'app\exception\ExceptionHandler'（少开头反斜杠）→ PHP 自动按当前命名空间解析，报错Class not found - 路径写成
app/exception/ExceptionHandler.php（用斜杠）→ 是文件路径，不是类名，PHP 会尝试加载名为app/exception/ExceptionHandler的类，失败 - 类存在但未声明
namespace app\exception;→ 即使文件放对位置，也无法被自动加载 - 开发环境
APP_DEBUG = true时，部分底层错误（如 ParseError、TypeError）会被调试器拦截，render()根本不执行——测试前务必切为false
区分请求类型：HTML 页面和 API 接口要不同响应
用户访问网页 vs 前端发 AJAX 请求，错误输出格式必须分开处理，否则 API 返回 HTML 会导致前端解析失败。
- 用
$request->isAjax()或$request->expectsJson()判断是否为 API 请求 - 网页请求走
response()->view()渲染app/view/error/404.html等模板 - API 请求必须用
response()->json()，并显式设头：->header('Content-Type', 'application/json') - 不要依赖
env('APP_DEBUG')决定是否返回堆栈——开发时也应返回标准 JSON 结构，仅在日志中记录详情 - 别在
render()里调app('view')->fetch()，视图引擎可能未初始化；改用response(view(...))->code(...)更稳妥
抛出异常时必须用框架异常类才能进 render()
throw new \Exception() 不会被你的 render() 拦截，它绕过 TP6 异常链，直接触发 PHP 默认处理器。
- 控制器中应抛
new \think\exception\HttpException(404, '资源不存在')或new \think\exception\ValidateException($errors) - 业务层可自定义异常类，但必须继承
\think\exception\HttpException，否则getStatusCode()方法不存在 - 验证失败时不要只改提示文字，要在控制器中捕获
$this->validate()返回值并主动 throw，否则仍走默认 422 页面 - 路由 404（如控制器/方法不存在）由
RouteNotFoundException触发，它属于HttpException子类，可统一判断$e instanceof HttpException
最易忽略的一点：所有自定义逻辑都集中在 render()，但日志记录必须放在 report() 里——这两个方法职责严格分离。render() 只管“怎么回给用户”，report() 才负责“记到哪、记什么”。混在一起会导致生产环境错误不落库、调试信息泄露到响应体。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
