404页面是服务器返回的HTTP状态码“Not Found”，表示请求资源不存在；而“无法连接到服务器”等属网络层失败，fetch会直接reject，需在catch中处理，不可混淆。
网络错误页面（如“无法连接到服务器”“网络不通”）和 404 页面根本不是一回事——前者是前端能感知的网络层失败，后者是后端返回的 HTTP 状态码。混淆这两者，会导致你用 window.location 跳转、或在 fetch 失败时渲染一个假 404，结果既没真实状态码，也没真正兜住错误。
fetch 失败时怎么显示网络错误页
浏览器发起请求但连不上服务器（DNS 失败、TLS 握手超时、跨域被拦、本地断网），fetch() 会直接 reject，不会进入 response.ok 判断分支。这时候你得在 catch 里处理，而不是等 response.status === 404。
- 必须用
try/catch包裹fetch()，不能只靠if (!res.ok) - 常见错误：把所有错误都重定向到
/network-error.html，但这个页面本身又依赖网络加载 JS/CSS，导致二次失败 - 推荐做法：内联关键 HTML + CSS，JS 逻辑尽量轻量；比如只保留“重试”按钮和“返回首页”，其他资源延后加载
- 如果用 React/Vue，别在组件挂载后才发请求——首次渲染就应预判网络状态，可用
navigator.onLine做粗略判断，但注意它不可靠（Wi-Fi 连着但网关宕机时仍返回true）
为什么不能用 window.location 跳转到网络错误页
因为跳转本身依赖网络：浏览器要重新 DNS 查询、建立 TCP 连接、下载新 HTML。当用户已处于断网状态时，window.location.href = '/offline.html' 可能卡死、白屏，或触发浏览器默认的“ERR_INTERNET_DISCONNECTED”页面。
- 静态资源（HTML/CSS/图片）必须能离线访问：把错误页所有依赖打包进单个 HTML 文件，或用 Service Worker 缓存
- 避免在错误页中调用任何外部 API、字体、CDN JS——它们都会失败并拖慢渲染
- 如果用了 Webpack/Vite，确认
public/下的offline.html没引用./assets/xxx.js这类相对路径资源（构建后路径可能失效）
Nginx/Apache 不会自动返回网络错误页
服务器配置的 error_page 502 /502.html 或 error_page 504 /timeout.html 只在 Nginx 自己遇到上游故障时生效，跟用户本地断网完全无关。这类配置对“用户没网”零作用。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
502 Bad Gateway是 Nginx 收不到后端响应，不是用户收不到 Nginx 响应 - 想覆盖用户断网场景，唯一可靠方式是前端主动检测 + 静态 fallback 页面
- 某些 CDN（如 Cloudflare）提供“Always Online”功能，但只缓存 HTML 主体，不保证 JS/CSS 可用，且对 SPA 路由无效
移动端断网提示容易被忽略的细节
Android Chrome 和 iOS Safari 对 navigator.onLine 的实现差异大，且系统级“无网络”提示常被 WebView 拦截或延迟触发。
- 不要仅靠
online/offline事件做 UI 切换——它们有明显延迟（iOS 上可达 30 秒） - 更稳妥的做法：对关键接口加超时（
AbortSignal.timeout(8000)），超时即视为网络异常 - 移动端需禁用双击缩放：
<meta name="viewport" content="width=device-width, user-scalable=no">，否则用户误触缩放后，错误页文字可能小到看不见 - 按钮点击区域至少 44×44px，避免误操作；“重试”按钮建议带 loading 状态，防止重复提交
真正的难点不在写页面，而在于让这个页面在最差的网络条件下也能秒出——这意味着你要放弃大部分现代前端工程化习惯：不引入框架、不拆分资源、不依赖构建产物路径、不假设用户能连上任意一个域名。越简单，越可靠。
