必须真实返回 HTTP 404 状态码，否则搜索引擎持续抓取死链、浏览器离线缓存 fallback 失效、PWA fetch 事件监听失效；需通过 curl -I 验证响应头含明确 404，禁用 302 跳转或伪状态；各平台配置须精准：GitHub Pages 仅识别根目录 404.html，Vercel 需 errorPages 配置，Nginx 的 error_page 后不可加 =200；首屏内容须纯 HTML+CSS 直出，禁止依赖 JS 渲染。
必须真实返回 HTTP 404 状态码，否则一切优化都失效
很多团队花时间设计精美 404 页面，却在部署时让服务器返回 200 OK —— 这会导致搜索引擎持续抓取“死链”，浏览器无法触发离线缓存 fallback 逻辑，PWA 的 fetch 事件监听也会失效。
验证方式很简单：curl -I https://yoursite.com/nonexistent，响应头里必须出现 HTTP/2 404 或 HTTP/1.1 404 Not Found。不是 302 跳转，也不是渲染完再塞个 status=404 的伪状态。
- GitHub Pages：只认根目录的
404.html，且不能带子路径（/a/404.html不生效） - Vercel：必须用
errorPages配置项，rewrites会覆盖状态码 - Nginx：确认
error_page 404 /404.html后面没加=200这类错误重写
纯 HTML + CSS 实现首屏可交互，别等 JS 加载
用户看到 404 时已经失败一次，再等 JS 下载、解析、执行才显示按钮或搜索框，体验雪上加霜。所有核心内容必须在 HTML 源码里直出。
关键结构示例：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
<h1>404</h1> <p>您访问的页面找不到了</p> <p>原始路径：<pre class="brush:php;toolbar:false;"> <p><code>location.pathname可在内联脚本中读取并填入
id="path-display"，但即使 JS 被禁用或加载失败，文字和链接仍可用。
- 避免用
history.back()做“返回上一页”按钮——外链进来的 404 会跳到空页甚至报错 - 所有导航链接用绝对路径（如
/、/help），不用相对路径（../） - 图标用内联 SVG 或 CSS 绘制，不依赖外部
.png或 CDN 字体
引导要分层，且每层都得是真实可点击的链接
用户此刻最需要的是“下一步动作”，而不是解释为什么出错。把信息按优先级组织，且每一项都必须指向一个真实存在的页面。
- 第一层：展示当前请求路径（
location.pathname），帮用户确认是否拼错 - 第二层：3–4 个高频目标链接（如
/products、/docs、/contact），地址必须真实可访问 - 第三层：站内搜索
<form action="/search">，后端需实际支持该路由；别调用 Algolia 或 Google Custom Search，离线即不可用
别放“报告此错误”按钮——除非后端真有日志接收接口并能关联 Referer 和 path。否则只是给用户多一个点击后无反馈的动作。
最容易被忽略的其实是服务端日志联动
前端再友好，如果服务端没记录每次 404 的原始 Referer 和完整 path，你就永远不知道是内部菜单链接写错了，还是爬虫在扫已下线的 API 路径。
检查你的 Nginx / Apache / Vercel 日志配置，确保以下字段至少有一项被采集：
-
$request_uri（含 query string） -
$http_referer（来源页面，判断是否站内跳转出错） -
$status（确认确实是 404，不是 500 被伪装成 404）
没有这三行日志，所有 404 页面设计都是盲修——你连该优化哪条链接都不知道。
