404页面必须真实返回HTTP 404状态码，不可仅前端跳转；推荐列表应硬编码或构建时内联JSON，用语义化HTML与ARIA提升可访问性，限制数量并确保链接为绝对路径。
404页面需要真实返回 404 状态码，不能只是显示文字
很多开发者用 location.href 跳转到一个“好看”的 404.html 页面，但服务器实际返回的是 200 状态码——搜索引擎和爬虫会把它当普通页面收录，推荐文章列表也白搭。必须确保：HTTP 响应头中包含 HTTP/1.1 404 Not Found。静态托管平台（如 GitHub Pages、Vercel、Netlify）通常支持自定义 404 页面，但只在真正 404 时触发；若本地用 file:// 打开，永远是 200，测试无效。
实操建议：
- GitHub Pages：把
404.html放在仓库根目录，文件名必须严格为404.html（大小写敏感） - Vercel：默认识别
public/404.html，无需额外配置 - Netlify：在
_redirects文件里加一行/* /404.html 404（注意末尾的404是状态码标识） - 本地测试请用
npx serve或python3 -m http.server启动本地服务，再手动访问一个不存在的路径（如/nonexistent）
推荐文章列表得靠前端静态数据或轻量 JS 渲染
404 页面通常是纯静态 HTML，没法连数据库或调 API。推荐列表只能来自三类来源：硬编码、JSON 内联、或从已有文章页提取元信息（如 ）。硬编码最稳，适合文章少于 10 篇的站点。
常见错误现象：用 fetch('/api/articles') 请求后端接口 —— 404 页面本身已说明路由失败，再发请求大概率 404 套娃，且无 fallback。
实操建议：
- 直接在
404.html里写死推荐链接，用语义化包裹 - 如果文章有统一结构（比如每篇 Markdown 都生成了
），可用 JS 扫描document.head.querySelectorAll('meta[name="title"]')抽取，但注意跨域和性能 - 更可靠的做法：构建时生成一个
recommended.json，内联进 HTML：<script type="application/json" id="rec-data">[{"title":"CSS Grid 布局实战","url":"/grid-practice"},{"title":"React.memo 的边界","url":"/react-memo-edge"}]</script>，然后用JSON.parse(document.getElementById('rec-data').textContent)读取
单纯堆砌推荐链接，屏幕阅读器可能把整个 404 页面当成一堆无关链接播报。必须明确主次：错误提示是主要内容，推荐列表是辅助导航。
使用场景：视障用户依赖 role 和 aria- 属性跳过重复区块。如果推荐区没标记，他们可能反复听到“推荐文章”“推荐文章”……
实操建议：
-
包住页面未找到
id="main-content" - 推荐列表用
，标题用你可能还想看
- 每个推荐项用
包裹，外不套—— 避免键盘 Tab 顺序混乱- 别用
display: none隐藏推荐区做“动画入场”，屏幕阅读器会直接忽略；改用opacity: 0; pointer-events: none;+ CSS 过渡别让推荐列表干扰 404 的核心目的：引导用户离开错误页
推荐文章列表不是首页，它的存在是为了降低跳出率，而不是让用户停留。如果列表太长、样式太抢眼、或自动播放视频/轮播图，反而模糊了“这个页面不存在”的信号。
性能影响：加载 10 个推荐封面图（哪怕 lazyload）仍会触发额外 HTTP 请求，拖慢 404 页面渲染。而用户平均停留时间不到 8 秒。
实操建议：
- 限制推荐数量：3–5 篇足够，最多不超过 7 篇
- 封面图一律用
width="80"以内，格式优先.avif或.webp - 避免任何 JS 动画、第三方统计脚本、或嵌入式评论框 —— 它们和 404 无关，且可能报错阻塞主线程
- 在推荐标题旁加小图标（如
），比“点击查看详情”文案更节省空间
最容易被忽略的一点：推荐链接的
href必须是绝对路径（如/blog/react-memo-edge），不能是相对路径（如../blog/react-memo-edge）—— 因为 404 可能发生在任意嵌套层级（/a/b/c/d/xxx），相对路径会拼错。 - 别用
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
