17370845950

应监听 online/offline 事件并结合主动 fetch 探测：页面加载时读取 navigator.onLine 初始值，绑定事件监听网络切换，再通过 HEAD 请求 /health 等 endpoint 验证服务可达性，避免仅依赖浏览器在线状态。

如何监听 navigator.onLine 的实时变化

navigator.onLine 是一个只读布尔值，但它**不会自动响应网络切换**——它只在页面加载时取一次初始值，之后除非手动触发或浏览器主动更新（如 Chrome/Firefox 在某些网络断开瞬间会同步更新），否则不会变。所以不能只靠轮询 navigator.onLine 来判断真实状态。

正确做法是监听全局的 online 和 offline 事件：

window.addEventListener('online', () => {
  console.log('已联网');
});
window.addEventListener('offline', () => {
  console.log('已离线');
});

• 这两个事件触发及时性依赖浏览器实现，Chrome 和 Firefox 支持较好；Safari 在某些 macOS/iOS 版本中对 offline 响应有延迟甚至不触发
• 事件只反映“系统级网络接口是否可用”，不是“能否访问目标服务器”。比如 Wi-Fi 已连但路由器断网，navigator.onLine 仍为 true
• 页面刚打开时，建议先读一次 navigator.onLine，再绑定事件，避免错过初始状态

为什么单纯靠 online/offline 事件不够用

这些事件无法检测以下真实业务场景：

• Wi-Fi 连接正常，但 API 接口返回 503 Service Unavailable 或超时
• 用户处于“飞行模式+手动开启 Wi-Fi”，navigator.onLine 为 true，但实际无上行路由
• 企业内网环境，DNS 不通或代理拦截，导致 fetch 失败，但浏览器认为“在线”

因此必须结合主动探测：

推荐用轻量 fetch 请求一个稳定、低开销的 endpoint（例如自己服务的 /health 或 https://www.google.com/generate_204）：

async function checkServerReachable() {
  try {
    const res = await fetch('/health', { method: 'HEAD', cache: 'no-cache' });
    return res.ok;
  } catch (e) {
    return false;
  }
}

• 不要用 GET 请求图片或空资源，容易被缓存或触发 CORS
• 加 cache: 'no-cache' 防止 Service Worker 或浏览器缓存干扰判断
• 避免高频轮询（如每秒一次），建议首次离线后延时 5–10 秒再探，或仅在用户操作前检查

离线时该做什么：缓存策略与 UI 反馈要点

检测到 offline 后，不能只弹个提示就结束。关键动作包括：

• 暂停所有非幂等请求（如 P

  

  OST / PUT），把它们暂存到 IndexedDB 或 localStorage，等恢复后再重放
• 禁用依赖网络的交互控件（如提交按钮、搜索框），并用 aria-busy="true" 或 CSS 类标明不可用状态
• 如果使用了 Service Worker，确保 precache 了核心静态资源（HTML/CSS/JS），否则离线时白屏
• 避免在 offline 事件回调里直接调 alert() —— 移动端可能被拦截，且打断用户操作流

UI 提示建议用轻量 toast，带明确恢复机制（如“重试”按钮），而不是全屏遮罩。

兼容性与移动端特殊行为注意点

Android WebView 和 iOS WKWebView 对 online/offline 事件支持不一致：

• 部分 Android 旧版 WebView 完全不触发这两个事件，需 fallback 到定时 fetch 探测
• iOS Safari 在后台标签页中可能冻结 JS 执行，导致事件延迟数秒甚至丢失
• PWA 应用若注册了 Service Worker，可通过 self.registration.update() + waiting 状态间接感知网络恢复（需配合 message channel）
• navigator.onLine 在 Electron 中反映的是主进程网络状态，渲染进程需通过 IPC 同步

真正健壮的网络状态管理，永远是「事件监听 + 主动探测 + 业务层兜底」三层组合。别指望单个 API 解决所有问题。