404页面生效需服务器真实返回404状态码且路径严格匹配，仅放404.html文件无效；须用curl验证响应头，配置Apache/Nginx规则，注意大小写、扩展名、平台限制（如GitHub Pages仅认根目录404.html），HTML须原生可访问、不依赖JS。
404错误页面不是前端“写出来就能生效”的HTML，而是必须由服务器真实返回404状态码、且路径与配置严格匹配的协作结果。光有404.html文件，90%的情况会返回200 OK——搜索引擎当它是正常页，浏览器也无从触发离线缓存或重试逻辑。
确认服务器是否真返回 404 状态码
这是所有问题的前提。很多开发者以为把404.html扔进根目录就万事大吉，其实服务器默认根本不会拦截并重写状态码。
- 用
curl -I http://localhost/nonexistent-path检查响应头，必须看到HTTP/1.1 404 Not Found，而不是200 OK - Apache：确保
.htaccess里有ErrorDocument 404 /404.html，且mod_alias已启用 - Nginx：在
server块中写error_page 404 /404.html;，并加location = /404.html { internal; }防止外部直连导致状态码变200 - GitHub Pages：只认仓库根目录下的
404.html，且仅对顶层路径生效（/foo/bar触发，但/docs/404.html不触发）
HTML 文件位置和访问路径必须完全一致
服务器找不到文件，从来不是因为“页面没写好”，而是路径对不上。大小写、扩展名、隐藏后缀、斜杠方向，全要抠准。
- Windows上注意文件可能是
about.html.txt，系统隐藏了扩展名；需在文件夹选项中开启“显示文件扩展名”才能确认 - Linux/macOS区分大小写：
About.html≠about.html，链接写错一个字母就404 - 本地双击
file:///打开永远不触发404——那只是浏览器读文件；必须走http://localhost/这类HTTP服务才有效 - 如果文件在
/pages/contact.html，访问地址就必须是http://localhost/pages/contact.html，少个pages/就是错
用纯 HTML + CSS 实现可依赖的 404 页面结构
别用 JS 渲染主文案或跳转逻辑。用户可能禁用 JS、网络中断、或页面加载到一半就失败——此时只有原生 HTML 能保证核心信息可见。
立即学习“前端免费学习笔记（深入）”；
-
<h1>404</h1>必须存在且为一级标题，不能是图片或 SVG 文本（除非加aria-label="404"） - 展示用户原本想访问的路径：
<code><script>document.write(location.pathname)</script>，帮助确认是否拼写错误 - 导航链接全部用
<a href="/">首页</a>，不用<button onclick="history.back()"></button>——外链进来的404点它会跳空页 - 搜索框用
<form action="/search" method="GET"><input name="q"></form>，不绑 JS，后端需真实支持/search?q=xxx
静态托管平台的特殊规则必须硬记
GitHub Pages、Vercel、Cloudflare Pages 这类平台不跑完整 Web 服务器，它们的404机制是预设逻辑，不认自定义配置。
- GitHub Pages：文件名必须是
404.html，且只能放在仓库**根目录**；/docs/404.html或/error/404.html一律无效 - Vercel：需在
vercel.json中配置"errorPages": true，并确保404.html在部署根目录；用rewrites做跳转不会改变状态码 - Netlify：支持
_redirects文件，但自定义404仍要求根目录下存在404.html，且路径不能带前缀 - 所有平台都不支持子路径级
404模板（比如/admin/404.html），那是传统服务器才有的能力
最容易被忽略的是：即使页面设计得再友好，如果服务端日志没记录原始Referer和request.path，你就永远不知道是内部链接写错了，还是爬虫在扫废弃路径——而这个问题，前端 HTML 一丁点都帮不上忙。
