webman 的 404 和 500 页面必须分别通过 route::fallback() 和自定义 handler::render() 配置；404 需置于路由末尾、区分 ajax/html 并显式调用 ->withstatus(404)，500 需重写 render() 方法并设状态码，否则默认返回 200，影响 seo 与调试。
Webman 的 404 和 500 页面必须分两路配置：404 用 Route::fallback()，500 用自定义 Handler 类；不这样做，页面能显示但状态码大概率是 200，SEO 和调试全失效。
Route::fallback() 是唯一可靠的 404 入口
Webman 不识别 resources/views/errors/404.blade.php 这类 Laravel 路径，也不走 Nginx 的 error_page 404。它只在路由完全未匹配时触发 Route::fallback()，这是你控制 404 响应的唯一正路。
- 必须把
Route::fallback()放在config/route.php最末尾，否则前置路由会拦截掉 - 要区分请求类型：AJAX 请求返回 JSON，普通请求返回 HTML 模板并显式调用
->withStatus(404) - 模板路径写
view('404')即可，Webman 默认从app/view/下找，不用写后缀 - 别在 fallback 里 throw 新异常——这会跳进 500 流程，而不是继续走 404
500 页面必须重写 Handler::render()
Webman 的 500 不由路由系统接管，而是由异常处理器决定。默认的 \support\exception\Handler 不渲染视图，直接吐错，所以你得自己写一个 app/exception/Handler.php 并在 config/exception.php 中注册。
-
render()方法里必须手动判断$request->expectsJson()，否则 API 请求也会返回 HTML - 返回视图时一定要链式调用
->withStatus(500)，否则响应头还是 200 - 模板中可用
$exception变量，但生产环境别直接输出$exception->getTraceAsString()，有信息泄露风险 - 如果用了中间件（如鉴权）抛出异常，确保中间件没提前捕获并吞掉异常，否则根本进不到这个
render()
静态资源和 AJAX 场景下容易漏掉的状态码
即使你写了 withStatus(404)，某些情况仍会返回 200：比如前端用 fetch 请求一个不存在的 API，后端 fallback 返回了 JSON，但没设 Content-Type: application/json，部分浏览器或代理可能“修正”状态码。
- 检查 Network 面板里的响应头，确认
Status是404 Not Found或500 Internal Server Error，不看页面文字 - 用
curl -I http://localhost/nonexistent验证，第一行必须是HTTP/1.1 404 - 如果页面里有 CSS/JS 加载失败，404 模板本身可能也加载不了样式——这不是 Webman 问题，是 Nginx/Apache 没配好静态资源 location
- 别在 404 模板里放
header("Location: /")或 JS 跳转，这会让状态码变成 302，搜索引擎当真
最常被忽略的是：Webman 的 fallback 和 Handler 都只对 PHP 层异常生效。Nginx 层面的 502/504、PHP-FPM 挂掉、或 max_execution_time 超时，这些根本不会走到你的 PHP 代码里，得靠 Web 服务器单独配 error_page 502 504 /50x.html 来兜底。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
