如何通过navigator.onLine与网络嗅探事件实现网页断网时自动触发逻辑熔断的机制？

本文共计784个文字，预计阅读时间需要4分钟。

不能仅依靠 `navigator.onLine` 做熔断，它仅反映系统接口状态，不是真实连通性判断依据。真正的自动熔断需结合事件监听、主动探测和状态收集，否则容易误熔断（如DNS故障时显示在线却无请求）或漏熔断（如路由器断网但onLine为true）。

用 online/offline 事件做快速状态捕获

这两个事件是熔断机制的触发入口，但要注意它们不冒泡、只在 window 上生效，且初始值不可信：

• 必须在页面加载后立即读取 navigator.onLine，手动判断初始状态是否需启动熔断逻辑
• 绑定监听时用 window.addEventListener('offline', handleOffline)，别绑在 document 或组件内部 DOM 上
• iOS Safari 后台标签页可能延迟触发，若业务强依赖实时性，需配合定时心跳兜底

用 fetch 探测实现“业务级”可用性验证

熔断依据不能是“有没有网”，而是“能不能调通关键接口”。推荐用同域轻量 endpoint（如 /health 或 /ping）做探测：

• 必须加超时控制：用 AbortController 设置 3 秒内无响应即判定失败，避免阻塞主流程
• 只捕获 TypeError（网络中断）和 AbortError（超时），忽略 4xx/5xx HTTP 状态码——它们不代表离线
• 避免轮询：用节流策略（如最小间隔 5 秒），首次加载完立刻探一次，后续仅在 offline→online 转换后重试

设计三态熔断状态机防止抖动

网络波动频繁时，直接根据事件开关熔断会反复触发，导致 UI 闪跳、请求乱序、表单被意外禁用。应引入状态收敛：

• 定义三个稳定状态：online（确认服务可达）、checking（刚恢复，正在验证）、offline（连续两次探测失败）
• 只有从 checking → offline 才真正启用熔断（如禁用提交按钮、暂停轮询、缓存待发请求）
• 从 offline → checking 时不立即恢复功能，等探测成功后再切到 online，避免“假恢复”

熔断后的自动恢复与请求重放

熔断不是终点，而是过渡。恢复逻辑要兼顾用户操作连续性：

• 检测到 online 后，先执行探测；仅当探测成功，才解除按钮禁用、重启定时任务、清空 loading 状态
• 对熔断期间用户已触发但未发出的请求（如表单提交、消息发送），可暂存至内存队列，恢复后按顺序重放
• 重放时需做幂等处理（如带唯一 traceId、服务端校验），避免重复提交