Webman的404必须用Route::fallback()定义，Nginx的error_page仅处理未达PHP层的请求；500需通过app/exception/Handler.php拦截并返回withStatus(404)；403需手动抛出或在fallback中判断；错误页资源须用绝对路径引用。
Webman 的 404 页面必须用 Route::fallback，不能靠 Nginx error_page
Webman 是基于 PSR-7 的常驻内存框架，所有请求默认由它接管；Nginx 的 error_page 404 只在请求连 index.php 都没匹配到时才触发（比如直接访问 /missing.css），而 Webman 的 404 是“路由未命中”，属于 PHP 层逻辑。两者不冲突，但分工必须清楚。
常见错误是：在 Nginx 配置里加了 error_page 404 /404.html，结果 Webman 的 Route::fallback 根本不执行——因为 Nginx 已经提前返回了静态页，根本没把请求转发给 PHP。
- Webman 的 404 必须写在
config/route.php中，用Route::fallback()注册回调 - 回调内可判断
$request->expectsJson()，区分 AJAX 和页面请求 - 返回
view('404')时，必须显式调用->withStatus(404)，否则状态码仍是 200 - 视图文件路径是
app/view/404.html（非 Blade，纯 PHP 模板），不要放错目录
500 页面要靠自定义异常处理器，不是改 Nginx 配置
500 错误本质是 PHP 运行崩溃（如语法错误、内存超限、未捕获异常），Nginx 的 error_page 500 只有在 PHP-FPM 成功返回 500 状态头时才生效；一旦 PHP 进程彻底挂掉，Nginx 只能返回原始错误文本。
所以 Webman 的 500 页面必须从框架层拦截：通过 app/exception/Handler.php 覆盖默认处理逻辑，而不是依赖 Web 服务器兜底。
立即学习“PHP免费学习笔记（深入）”；
- 必须在
config/exception.php中注册该 Handler：return ['' => \app\exception\Handler::class]; -
render()方法里要检查$request->expectsJson()，避免 JSON 请求被塞进 HTML 模板 - 视图
app/view/500.html里别调用asset()或url()辅助函数——异常发生时这些服务可能已不可用 - 若 500 页面自身出错（比如引用了不存在的变量），会二次崩溃并 fallback 到 Nginx 默认页
403 页面需手动注册路由或复用 fallback，Webman 不自动识别
Webman 默认不为 403 状态码提供专用钩子，Route::fallback() 只响应 404 和 405（从 1.5.23 开始支持传入 $status 参数），403 必须显式抛出或拦截。
两种可靠做法：
- 在中间件或控制器中主动抛出：throw new \Webman\Exception\HttpException(403, 'Forbidden')
- 在
Route::fallback()回调里加判断：if ($status === 403) { return view('403')->withStatus(403); } - 对应视图文件名必须是
app/view/403.html，且内容中避免动态 PHP 逻辑（异常上下文不稳定） - 不要指望 Nginx 的
error_page 403—— Webman 的权限控制发生在 PHP 层，Nginx 压根不知道 403 是哪来的
静态资源加载失败？错误页里的 CSS/JS 路径别依赖运行时
Webman 的错误页是在异常中断后渲染的，public/ 目录映射、Asset Bundle、URL 生成器等都可能失效。你看到样式全无、图标 404，大概率是路径解析错了。
最稳妥的方式是写死绝对路径：
- HTML 中用
<link href="/css/error.css">，而非{{ asset('css/error.css') }} - CSS 文件必须真实放在
public/css/error.css，确保 Nginx/Apache 能直出 - 图片同理：用
<img src="/images/404-icon.png">，不要用storage_path()或相对路径 - 如果用了 CDN，确保 URL 是完整 HTTPS 地址，避免混合内容被浏览器拦截
