navigator.online 不可靠，仅反映系统网络接口状态而非服务可达性，需配合 fetch 心跳检测（带超时、防抖、真实后端校验）和服务端预缓存离线页才能准确判断用户可用性。

单独用 navigator.onLine 显示“无网络提示”基本不可用——它在路由器断网、DNS 失效、代理异常时仍返回 true，但用户实际已无法访问你的 API。

为什么 navigator.onLine 不能信

这个属性只反映操作系统网络接口是否启用，不是服务可达性判断。比如 WiFi 图标亮着，但光猫掉线、防火墙拦截了你的域名、CDN 返回 503，navigator.onLine 依然为 true。它只在你手动关 WiFi 或开飞行模式时才准确变 false。

• 安卓 WebView 默认不触发 offline 事件，iOS WKWebView 有已知 bug，完全不派发
• 事件延迟常见：从真实断网到触发 offline 可能长达 2–5 秒，甚至不触发
• 它无法区分“连得上但后端挂了”和“完全没网”，而用户真正关心的是“我的页面还能不能用”

必须搭配 fetch 心跳检测才靠谱

前端要确认的从来不是“有没有 IP 连接”，而是“能不能拿到 /api/ping 的 200 响应”。心跳必须带超时、防抖、且 endpoint 由后端真实校验依赖（如 DB 连通性），不能只是返回静态 200。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 用 AbortController 控制超时，例如 setTimeout(() => controller.abort(), 3000)，避免 fetch 卡死
• 不要请求 /、/favicon.ico 或 CDN 资源——它们可能被缓存或绕过服务端，无法反映真实状态
• 心跳间隔建议 ≥15 秒；太频繁会触发 CORS 预检、耗电、被服务端限流
• 收到 online 事件后，别立刻隐藏提示，先发一次心跳，成功再更新 UI 状态

Service Worker 离线页必须预缓存且自包含

想让用户断网后点刷新还能看到提示页，核心不是 JS 判断，而是 Service Worker 在 install 阶段就把 /offline.html 写进 cache，并在 fetch 事件中对导航请求（request.mode === 'navigate'）直接返回它。

• 缓存路径必须严格一致：install 里 cache.addAll(['/offline.html'])，fetch 里就只能用 caches.match('/offline.html')
• /offline.html 必须内联所有 CSS/JS，不能引用任何外部资源（包括 Google Fonts、CDN jQuery），否则自己加载失败就白屏
• 返回响应要用 new Response(body, { status: 503, headers: { 'Content-Type': 'text/html' } })，不能用 Response.redirect()（离线时重定向会失败）
• 注册 SW 后调用 registration.waiting.postMessage('skipWaiting')，否则新版本卡在 waiting 状态，断网时仍走旧逻辑

提示文案和动画容易被忽略的细节

网络抖动时，online/offline 事件 + 心跳失败可能密集触发，导致“重新连接中…”反复闪现，体验极差。

• 加 1.5 秒防抖：收到离线信号不立即显示，等 1.5 秒没恢复再 show；收到 online 后也不立即 hide，先心跳成功再收起
• 用 CSS opacity + pointer-events: none 控制显隐，别反复增删 DOM 元素，避免重排
• 文案统一用“重新连接中…”，不要写“第 2 次尝试…”——干扰信息毫无意义，还增加 DOM 更新负担
• 记录上次状态变更时间戳，若两次离线间隔

最常翻车的点不在逻辑多复杂，而在缓存路径少个斜杠、offline.html 里多引了一个 CDN 字体、或者忘了 response.clone() 导致缓存写入空 body——这些都会让离线页在关键时刻彻底消失。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！