JavaScript处理网络断开与离线降级需结合navigator.onLine状态检测、online/offline事件监听、请求层错误分类（如TypeError: Failed to fetch）、轻量心跳验证及本地缓存/队列同步策略，确保体验可靠可用。
在 JavaScript 接口调用中处理网络断开与离线降级，核心是主动检测连接状态 + 捕获请求失败 + 提供可用兜底策略，而不是只依赖错误回调。浏览器原生提供了基础能力，但需合理组合使用。
监听网络状态变化
利用 navigator.onLine 和 online/offline 事件可感知全局联网状态变化，但它有局限：仅反映浏览器是否认为“在线”，不保证实际能连通服务器（比如 WiFi 未认证、代理异常）。因此适合做快速前置判断，不能替代请求层容错。
- 页面加载后立即检查：
if (!navigator.onLine) { showOfflineUI(); } - 绑定事件监听：
window.addEventListener('offline', () => showOfflineUI());window.addEventListener('online', () => tryReconnect()); - 注意：iOS Safari 在后台标签页可能不触发
online事件，建议配合定时轮询或下一次用户交互时再校验
请求层统一拦截与重试控制
所有 fetch / axios 请求应经过封装，在发起前、失败后做标准化处理。重点不是“重试几次”，而是“什么情况下不该重试”。
- 发起前快速检查：
if (!navigator.onLine) return Promise.reject(new Error('offline')); - 捕获网络类错误：fetch 失败时，
TypeError: Failed to fetch或AbortError通常表示断网或中断；HTTP 状态码如0（非标准但常见于断连）也属此类 - 对明确的网络错误（非 4xx/5xx），可延迟重试（如 1s 后），但最多 1–2 次；若连续失败，进入离线模式
- 避免无意义重试：如 POST 提交表单，重复发送可能造成数据重复，应禁止自动重试，改由用户手动触发
离线时启用本地降级策略
降级不是“什么都不做”，而是提供有限但可用的体验：
立即学习“Java免费学习笔记（深入）”；
- 读操作：优先从 IndexedDB 或 localStorage 读取缓存数据（需提前按接口维度缓存，带时间戳或版本号）；若无缓存，显示友好提示（如“暂无网络，显示最近数据”）
- 写操作：将操作暂存到队列（如内存或 IndexedDB），待恢复在线后自动同步；同步失败时保留记录，支持用户查看/重发
- UI 反馈：顶部常驻提示条（非弹窗），说明当前为离线模式，并告知哪些功能受限；操作按钮可置灰或显示“离线暂存”状态
恢复在线后的智能同步与状态刷新
网络恢复不等于服务就绪，需验证真实连通性并协调本地与远端状态：
- 触发
online事件后，先发一个轻量探测请求（如/health或 HEAD 到 API 域名），确认服务可达再启动同步 - 同步顺序建议：先上传离线队列（POST/PUT），再拉取最新数据（GET），避免本地旧数据覆盖服务端新内容
- 对 GET 请求，可对比缓存的 ETag 或 last-modified，只更新真正变更的数据，减少流量和渲染开销
- 同步完成后，刷新关键视图（如列表、计数 badge），并移除离线提示
不复杂但容易忽略的是状态一致性——本地缓存、UI 展示、离线队列、服务端数据之间要有一套明确的更新规则。用好 navigator.onLine、合理分类错误类型、分场景设计降级动作，就能让应用在网络波动时依然可靠可用。
