HTML本身不能处理404错误，真正决定返回404状态码的是服务器或后端逻辑；前端HTML只是被服务端决定是否返回的资源，必须通过服务端配置（如Nginx error_page、Apache ErrorDocument）或动态脚本（如PHP http_response_code(404)）显式声明，才能确保真实返回404状态码并正确展示自定义页面。
直接说结论：HTML 本身不能“处理”404错误，真正决定是否返回 404 的是服务器或后端逻辑；前端 HTML 文件只是被服务端决定“要不要返回”的一个资源。想让访问不存在路径时显示自定义页面且返回正确状态码，必须靠服务端配置或动态脚本干预。
为什么在浏览器里打开 file:///xxx/index.html 不会触发 404
因为这不是 HTTP 请求，压根没经过服务器。浏览器直接读取本地文件系统，找不到就报系统级错误（如“无法加载网页”），不会发 404 Not Found 响应。所有关于 404 的讨论，前提都是通过 http:// 或 https:// 协议访问，由 Web 服务器（Nginx/Apache/Tomcat/Next.js 等）参与响应流程。
Nginx 配置 error_page 404 却返回 200 怎么办
这是最典型的“软 404”陷阱：页面内容看着像 404，但响应头是 200 OK。根本原因是 Nginx 默认把 /404.html 当作普通静态文件返回，不继承 404 状态。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 确认
error_page 404 /404.html;后面没有等号（=），写成error_page 404 = /404.html;会强制覆盖状态码为 200 - 在
location = /404.html块中加internal;，防止用户直接访问该路径绕过 error_page 机制 - 用
curl -I http://localhost/nonexistent-path验证响应头，别只看浏览器页面 - 确保
/404.html文件真实存在于root指令指定的目录下，且 Nginx worker 进程有读取权限
SPA（如 React/Vue）路由 404 为何总 fallback 到首页
因为前端路由本质是 URL 操作，不发真实请求；而服务端不知道这些路由规则，所以对 /user/123 这种路径，它只认文件系统或后端接口是否存在。常见 try_files $uri $uri/ /index.html; 就是让所有未命中静态文件的请求都落到 index.html，再交由 JS 路由接管——但这会导致所有无效路径都返回 200。
立即学习“前端免费学习笔记（深入）”；
- 若需真实 404，必须在 JS 中判断当前路径无匹配路由，然后调用
history.replaceState(null, '', '/404')并渲染错误组件（仅视觉补救，状态码仍是 200） - 要真正返回 404 状态码，得配合服务端：Nginx 对已知 SPA 路由前缀（如
/api/、/static/）做显式匹配，其余全部return 404;，再用error_page 404 /404.html; - Next.js/VitePress 等框架自带 pages/404.js 或 .md，它们会在构建期生成对应路由并由服务端自动返回 404 状态，不用手动配
最容易被忽略的一点：即使你写了完美的 404.html，只要服务端没让它以 404 状态码发出，对搜索引擎来说它就等于一个普通页面——死链照爬，权重照掉。验证永远比写页面重要。
