html无法捕获404错误，真正决定状态码的是服务器或后端；前端唯一可靠方式是服务端注入标识（如），并确保返回真实404状态码而非200。
HTML 本身无法捕获 404 错误——它只是静态标记语言，不参与 HTTP 状态码的生成或判断。真正决定是否返回 404 的是服务器（如 Nginx、Apache）或后端逻辑（如 Express、Next.js），而浏览器只接收并渲染响应。所谓“在 HTML 里捕获 404”，本质是误解；你实际能做的，是确保 404 状态被正确返回，并让这个页面在视觉和语义上合理可用。
为什么 window.onerror / fetch 失败不等于页面级 404
window.onerror 捕获的是 JS 运行时错误，fetch() 的 catch 只能拿到网络请求失败（如 CORS、断网），但不会触发页面主文档加载失败的 404。当用户直接访问一个不存在的 URL（比如 /nonexistent），浏览器发起 GET 请求，服务端返回 404 Not Found 响应头 + HTML 内容——此时 JS 还没执行，更谈不上监听。
- 你在
/404.html里写window.onerror，只能捕获该页面自身 JS 的报错，不是“捕获 404” -
document.addEventListener('error', ...)只对图片、脚本等子资源加载失败有效，对主 HTML 文档无效 - 想在前端感知“当前页是 404”，唯一可靠方式是服务端注入标识（如
），但前提是你要控制服务端输出
如何让 404 页面真正返回 404 状态码
这是最关键的一步。很多所谓“404 页面”实际返回的是 200 OK，只是 HTML 里写了 “404 Not Found” 四个字——这对 SEO 和用户体验都是灾难。
- Nginx：用
error_page 404 /404.html;，并在location = /404.html块中加internal;，确保路径存在且无重定向 - Apache：
ErrorDocument 404 /404.html，路径必须以/开头，文件大小 ≥512 字节 - Next.js：把
pages/404.js放在根目录，它会自动返回 404 状态；但若你在getServerSideProps中抛错或调用redirect，状态可能退化为 200 - 静态托管（如 GitHub Pages）：只认根目录下的
/404.html，且必须直接访问该路径（不能通过 JS 跳转过去）
验证方式：打开 DevTools → Network 标签，刷新一个明显不存在的路径（如 /xyz-abc），看响应头第一行是不是 HTTP/1.1 404 Not Found。
404 页面里能做什么有用的前端操作
既然不能“捕获”，那就专注让它更有用。一个合格的 /404.html 应该：
- 内联所有 CSS 和 JS（避免额外请求失败导致样式崩溃）
- 用
<svg></svg>或纯 CSS 绘制 404 图标，不依赖外部图片 - 提供搜索框，把用户输入自动塞进
q=参数跳转到搜索页（如<form action="/search"><input name="q" value=""></form>） - 加一个回首页链接：
@#@#@#@#@#@#@#@#@#@0，不要用 JShistory.back()（可能回到错误页） - 禁止
<meta http-equiv="refresh">或window.location.href自动跳转——这会让状态码变成 200，Google 会标记为软 404
复杂点在于：服务端配置错一条规则，前端再努力也白搭。最容易被忽略的是 Nginx 的 error_page 默认做内部重写，不是重定向——你以为跳到了 /404.html，其实地址栏没变，状态码还是 404，这反而是对的；如果真要跳转（比如带原始路径去搜索），得用命名 location 配合 return 302，而不是指望 HTML 自己搞定。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
