不能仅凭online/offline事件判断api可达性，因其仅反映操作系统网络接入状态；需配合轻量心跳探测（如fetch('/health'）验证服务真实可用性，并依据探测结果驱动ui与重试逻辑。
不能只靠 window.addEventListener('online') 和 offline 就认为网络“真通”或“真断”——它们只反映操作系统层的网络接入状态，不是你的 API 是否可达。
online/offline 事件触发时机和局限性
这两个事件绑定在 window 上，offline 在用户手动关 WiFi、拔网线、开飞行模式时较可靠地触发；online 则在系统检测到任意网络接口激活（哪怕只是连上一个没网的路由器）就立刻触发。常见失效场景包括：
- WiFi 已连但光猫断网，
navigator.onLine仍为true，online不会触发 - 代理配置错误或 DNS 失效，页面打不开，但事件毫无反应
- 移动端锁屏后 WebSocket 断连，
navigator.onLine保持true，online完全不触发
基础监听写法与必须做的清理
用 addEventListener 注册是标准做法，但别忘了在组件卸载或页面离开前移除监听，否则可能引发内存泄漏或重复执行：
const handleOnline = () => console.log('系统报告上线');
const handleOffline = () => console.log('系统报告下线');
window.addEventListener('online', handleOnline);
window.addEventListener('offline', handleOffline);
// 清理示例（如 React useEffect cleanup 或 SPA 路由离开时）
// window.removeEventListener('online', handleOnline);
// window.removeEventListener('offline', handleOffline);
注意：window.ononline/window.onoffline 属性写法已被弃用，不要用；也不要用 document 或 body 绑定——事件只在 window 上冒泡生效。
为什么 online 回调里不能直接重发请求
因为 online 触发时，你的服务很可能还没响应。常见错误是：一收到 online 就立刻 fetch('/api/submit')，结果 503 或超时，用户看到“已联网”又马上报错，体验极差。正确做法是：
- 在
online回调中只启动一次轻量心跳探测（如fetch('/health', { method: 'HEAD' })） - 用
AbortController设 3–5 秒超时，避免卡死 - 仅当心跳成功且返回预期状态码（如 200 或 204），才标记“服务可用”，并触发重试队列
- 心跳 endpoint 必须真实穿透到后端（不能是 CDN 缓存的
/favicon.ico），且后端应检查 DB 连接等核心依赖
真正需要关心的是“API 是否可达”，不是“有没有网”
前端 UI 状态（比如显示“重新连接中…”）应该由心跳结果驱动，而不是 navigator.onLine 或 online 事件单独决定。网络抖动时，online/offline 可能高频切换，而心跳失败更稳定反映服务中断。最常被忽略的一点是：你永远无法靠单次心跳 100% 确认“下一秒请求一定成功”，所以重试逻辑必须带退避、限频和失败降级（比如本地缓存+用户确认再发）。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
