thinkphp 5.1+ 的异常处理由 app/exception.php 中注册的自定义 handler 类控制，需继承 think\exception\handle 并重写 render() 方法，返回带正确 http 状态码的 response 对象，模板应置于 resources/view/error/ 下按状态码命名，禁止输出敏感信息，且须确保环境配置、类加载和缓存清理到位。
ThinkPHP 5.1+ 的异常处理机制在哪改
默认报错页面由 think\exception\Handle 类控制，实际生效的是它在 app/exception.php（或 app/common/exception.php）中注册的处理器。不是改模板路径，而是重写这个类的行为。
常见错误现象：开发环境看到白屏+堆栈，线上却还是显示原始错误信息，说明没正确切换环境或没覆盖默认处理器。
- 确认
APP_DEBUG已设为false（线上环境必须关调试） - 在
app/exception.php中返回自定义异常类实例，而不是直接修改think\ExceptionHandle - 自定义类必须继承
think\exception\Handle，且重写render()方法
如何让 render() 返回一个带状态码的友好页面
render() 方法接收 $e（Throwable 实例），你要在这里判断异常类型、设置 HTTP 状态码、并返回 Response 对象。不能只 echo HTML，否则状态码仍是 200，SEO 和前端逻辑会出问题。
使用场景：404 页面要返回 404 状态，500 错误要返回 500，避免被搜索引擎收录错误页。
- 用
$e instanceof HttpException判断是否是路由/控制器层异常（如 404、405） - 用
$e->getStatusCode()获取原状态码（HttpException子类才有） - 非 HTTP 异常统一走 500，但建议记录日志：
Log::error('Server error: ' . $e->getMessage()); - 返回页面时用
view()或response()->view()，确保状态码透传：return response($content, $code)->header('Content-Type', 'text/html');
友好的提示页模板怎么接入又不破坏原有结构
不要把提示页硬编码进 render()，应复用 ThinkPHP 的视图系统。模板路径推荐放在 resources/view/error/ 下，和业务视图分离，避免被误删或污染。
参数差异：不同异常需要传不同变量给模板，比如 404 传 ['title' => '页面找不到了', 'message' => '您访问的地址可能已被删除或从未存在过']，而 500 传更谨慎的提示（不暴露敏感信息）。
- 模板文件名建议按状态码命名：
404.html、500.html，便于后续 Nginx/FastCGI 缓存映射 - 模板里禁止输出
$e->getTraceAsString()或任何$_SERVER原始数据——这是安全红线 - 如果用了多语言，可在
render()中根据Lang::getLangSet()动态选模板，但别在模板里做语言判断
为什么有些异常还是跳不过去，比如 PDO 连接失败
这类底层异常（如数据库连接中断、Redis 超时）往往在框架初始化阶段就抛出了，甚至早于 app/exception.php 加载。它们不会经过你写的 render()，而是被 PHP 默认错误处理器捕获。
性能影响：如果在 render() 里尝试连接数据库来查错误日志，反而会让 500 页面更慢甚至死循环。
- 在
public/index.php顶部加set_exception_handler()拦第一道（仅兜底，不替代render） - 数据库配置错误等致命问题，建议用
try/catch包裹require __DIR__.'/../thinkphp/start.php';，提前响应 - 检查
config/app.php中的'exception_handle' => \app\exception\Handler::class是否指向你的类，拼写错误会导致静默失效
最易忽略的是环境配置和类自动加载路径——改完代码后清空 runtime/cache/ 和 composer dump-autoload，否则新异常类根本不会被加载。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
