404页面需服务器、路径、状态码、HTML四者协同；本地双击无法触发404因file://无HTTP状态码；必须通过本地服务测试并用curl验证响应头；GitHub Pages等仅识别根目录下严格命名的404.html；搜索框须用原生GET表单且action为完整路径；跳转首页应使用location.replace("/")并确保DOM就绪；须保留可见的404避免被判定为软404。
404页面不是“放个HTML就能用”的静态文件，而是服务器、路径、状态码、HTML结构四者严丝合缝协作的结果；任意一环出错，用户看到的仍是默认错误页或200 OK。
为什么本地双击打开404.html永远不触发404
浏览器通过file:///协议加载文件时，根本不走HTTP协议栈，没有状态码概念，自然不会触发任何404逻辑。所有测试必须走http://localhost或真实域名。
- 开发阶段用
npx serve、python3 -m http.server 8000或VS Code Live Server插件起服务 - 切勿依赖GitHub Pages预览按钮——它只模拟渲染，不模拟HTTP状态码返回
- 验证是否真404：终端执行
curl -I http://localhost/nonexistent-path，必须看到HTTP/1.1 404 Not Found
404.html文件名和位置的硬性约束
GitHub Pages、Vercel、Netlify、Cloudflare Pages全部只识别根目录下严格命名为404.html（全小写、无空格、无BOM、无隐藏扩展名）的文件。其他命名如error-404.html、404.htm、pages/404.html均无效。
- Windows用户务必在文件夹选项中开启“显示文件扩展名”，确认不是
404.html.txt - Git提交后运行
git ls-files | grep 404，确保索引中确实是404.html - Jekyll用户需在
404.html开头加---\npermalink: /404.html\npublished: false\n---，否则会被当作普通页面渲染
搜索框必须用
404页面是纯静态HTML，浏览器不执行服务端逻辑；所谓“搜索”只是把用户输入转发给已有的站内搜索页，不是在当前页查数据。加JS拦截表单、用fetch或history.pushState只会让表单失效或SEO降权。
-
input必须带name="q"（或你后端实际接收的参数名），否则提交后URL里没查询参数 - 避免
onsubmit="return false"或event.preventDefault()，这会让表单完全无法提交 - 如果搜索页真实路径是
/blog/search，action就得写完整，不能简写为search - 加
autofocus属性即可实现默认聚焦，无需额外JS
跳转首页别用window.location.href = "/"
在404页面中直接赋值href容易被Service Worker缓存覆盖、DOM未就绪时执行失败，或导致用户点「返回」又回到空白错误页。更可靠的是location.replace("/")，且必须等DOM加载完成后再触发。
- 把跳转脚本放在
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
