404错误无法由HTML静态生成，动态提示需通过前端路由或服务端响应实现；SPA中用兜底路由组件，静态站点用404.html+JS解析pathname，服务端404与前端路由404须严格分离。
404错误信息不能靠HTML本身动态生成
HTML是静态标记语言，document加载完成时，页面状态就固定了；所谓“动态404提示”，实际是指在前端路由（如 SPA）或服务端响应失败后，由 JavaScript 主动更新 DOM 显示提示。如果你直接打开一个不存在的 HTML 文件（比如 /missing.html），浏览器根本不会加载你的 HTML —— 它会直接由服务器返回 404 响应，此时你写的任何 JS 都没机会执行。
React/Vue 等 SPA 中怎么显示动态404页
这类框架把路由控制权交给了前端，当用户访问 /unknown-route 时，服务器仍返回 index.html，JS 启动后才由路由库匹配路径。这时你可以定义一个兜底路由组件：
```jsx
// React Router v6
<Routes>
<Route path="/" element={<Home />} />
<Route path="*" element={<NotFound message="页面找不到了，请检查 URL" />} />
</Routes>
```-
message可以从 URL 参数、历史状态或配置中动态传入，比如useLocation().state?.reason - 不要在
NotFound组件里调用fetch('/api/xxx')渲染 404 内容 —— 这会让真实 404（服务端资源缺失）和前端路由 404 混淆，不利于 SEO 和调试 - 确保在组件内设置
<title>404 - 页面未找到</title>和<meta name="robots" content="noindex">
纯静态站点想模拟动态提示？用 404.html + JS 检查当前路径
GitHub Pages、Vercel、Netlify 等平台允许你放一个 404.html，当发生 404 时服务器会返回它（注意：不是重定向）。你可以在里面写 JS 解析 window.location.pathname，给出更友好的提示：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
```html
<script>
const path = window.location.pathname;
const $msg = document.getElementById('error-message');
if (path.includes('blog/')) {
$msg.textContent = `博客文章 "${path.split('/').pop()}" 不存在`;
} else if (/^\/[a-z]{2}\/$/.test(path)) {
$msg.textContent = `该语言版本暂未上线`;
} else {
$msg.textContent = `找不到页面：${path}`;
}
</script>
```- 这个方案只适用于托管平台支持自定义 404 页面的场景；Apache/Nginx 默认不执行
404.html里的 JS（除非你显式配置ErrorDocument 404 /404.html并确保 MIME 类型正确） -
window.location.pathname是用户输入的原始路径，不是服务器重写的路径，所以可安全用于提示 - 别尝试用
fetch(path)判断资源是否存在 —— 跨域、CORS、预检失败会让你的提示卡住或报错
服务端返回 404 时，前端 JS 无法捕获的原因
这是最容易被误解的一点：当你在浏览器地址栏输入 https://example.com/nonexistent.js，控制台报 Failed to load resource: the server responded with a status of 404 ()，但你写在 <script> 里的 onerror 或 catch 根本收不到 —— 因为脚本加载失败不会触发 Promise reject，也不会抛出可捕获的 JS 异常。
立即学习“前端免费学习笔记（深入）”；
- 只有通过
fetch()或XMLHttpRequest主动请求时，才能拿到response.status === 404 -
<img src="xxx">的onerror可以捕获，但仅限该标签；<script src="xxx">的onerror在多数浏览器中不可靠，尤其模块化脚本 - 真正需要“动态感知 404”的场景（如 CMS 预览、低代码编辑器），应该走 API 接口校验，而不是依赖资源加载结果
服务端 404 和前端路由 404 是两套机制，混用会导致提示错乱、SEO 降权、调试困难。最稳妥的做法是：服务端资源真缺失，就让服务器返回标准 404 响应头 + 自定义 404.html；前端路由缺失，由框架路由控制并渲染对应组件。两者边界必须清晰。
