navigator.onLine 不可靠，仅反映网络栈状态而非真实连接；应结合 AbortController 控制的 fetch 心跳检测（如 /api/ping）判断服务可达性，并加防抖和 CSS 过渡优化提示体验。
监听 navigator.onLine 不能直接信
浏览器的 navigator.onLine 只反映当前网络栈是否“认为”连上了，不是真实连接状态。比如 WiFi 已连但路由器断网、代理失效、DNS 拒绝响应，navigator.onLine 仍可能返回 true。它只在用户手动禁用网络（如关 WiFi、开飞行模式）时才可靠触发 false。
实操建议：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 不要单独依赖
navigator.onLine显示“重新连接中…”——它会漏掉大量真实中断场景 - 把它当作快速前置判断：若为
false，立刻显示提示；若为true，仍需发起心跳检测确认服务可达 - 监听
online和offline事件时，注意事件可能延迟几百毫秒甚至更久，别指望它实时
用 fetch() 心跳检测判断后端是否真通
前端真正需要知道的是“能否访问我们的 API”，而不是“有没有 IP 连接”。最稳的方式是定期发一个轻量 fetch() 到一个稳定 endpoint（比如 /health 或 /api/ping），根据响应状态和超时决定 UI 状态。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 心跳请求必须设
timeout（用AbortController），默认 fetch 没超时机制，卡住会阻塞后续判断 - 避免用
GET /或静态资源路径（如/favicon.ico），它们可能被 CDN 缓存或绕过后端，无法反映真实服务状态 - 后端
/health应检查数据库连接、核心依赖等，不能只是返回200 OK - 示例关键逻辑：
const controller = new AbortController(); setTimeout(() => controller.abort(), 5000); fetch('/api/ping', { signal: controller }) .then(r => r.ok ? setOnline() : setOffline()) .catch(() => setOffline());
“重新连接中…” 文本要防重复渲染和闪动
网络抖动时，online/offline 事件和心跳失败可能高频触发，导致提示反复出现/消失，用户体验极差。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 加防抖：收到离线信号后，等 1.5 秒没恢复再显示提示；收到在线信号后，先发一次心跳，成功后再隐藏提示
- 用 CSS 控制显隐而非增删 DOM，避免重排；推荐
opacity+pointer-events: none配合过渡动画 - 记录上次状态变更时间，如果两次离线间隔
- 别在每次心跳失败都更新文案——统一用“重新连接中…”，不写“第 3 次尝试…”这类干扰信息
移动端 WebView 和 PWA 的兼容性坑
在 iOS Safari、微信 WebView、某些安卓 PWA 中，navigator.onLine 行为更不可靠，且 online 事件可能根本不触发；部分 WebView 甚至会缓存 fetch() 响应，导致心跳永远成功。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对 WebView 场景，强制加
cache: 'no-store'和随机 query（如?t=123456789）防止假成功 - iOS Safari 下，
offline事件可能延迟数秒甚至不触发，必须依赖心跳；可配合pagehide事件提前标记“疑似离线” - PWA 的 Service Worker 会劫持所有请求，确保你的心跳 URL 不被
cacheFirst策略拦截——在 SW 中明确放行/api/ping - 测试时别只用 Chrome DevTools 的“Offline”模拟，一定要在真机断网、切飞行模式、拔网线等场景验证
navigator.onLine 是开关，fetch() 心跳是探针，UI 提示是结果——三者缺一不可，而且每层都要防住自己的失效路径。最容易被忽略的，是把“能发请求”等同于“服务可用”，其实中间隔着 DNS、TLS 握手、负载均衡、后端队列……一层没通，提示就该亮。 
