网络状态监测本身不产生高频回调，节流应作用于主动探测逻辑（如定时心跳、可见性切换后的检查），而非online/offline事件；因navigator.online仅反映浏览器离线模式，无法判断真实连通性，需结合节流封装的fetch探测来实现可靠判断。
前端网络状态监测本身不产生高频回调，navigator.onLine 是一个只读属性，变化时不会自动触发事件；真正高频的是你主动轮询或监听的自定义逻辑。所以“节流合并高频回调”不是用于 onLine 变化本身，而是用在你为判断真实连通性而设计的**主动探测行为**上——比如定时发心跳请求、重复检查 fetch 能否成功、或监听多个资源加载状态等场景。
为什么网络探测需要节流
直接每秒执行一次 fetch('/health') 或频繁轮询会带来明显问题：
- 短时间内大量请求堆积，增加服务端压力和前端内存开销
- 移动端下频繁唤醒网络模块，显著耗电
- 多个组件各自发起探测，造成重复请求和状态不一致
- 用户刚切回页面就触发密集探测，可能干扰首屏渲染
节流适用于哪些网络探测方式
节流不是加在 online/offline 事件上（它们本身极少触发），而是加在以下主动探测逻辑中：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 定时心跳请求：每隔固定时间（如 30s）发一次健康检查请求，用节流确保即使手动调用多次也只按节奏执行一次
- 页面可见性变化后探测：用户切回 tab 时可能批量触发多个组件的重连逻辑，用节流统一收敛到一次探测
- 资源加载失败兜底重试：图片、脚本加载失败后尝试重新获取，若多个资源同时失败，节流可避免瞬间发出十几条请求
如何实现带节流的真实连通性探测
不要只依赖 navigator.onLine（它只反映浏览器是否处于离线模式，无法判断真实网络是否可达）。推荐组合使用：
- 监听
window.addEventListener('online', ...)和offline做粗粒度切换 - 用节流封装一次真实的探测函数，例如：
try {
await fetch('/api/ping', { method: 'HEAD', cache: 'no-store' });
return true;
} catch {
return false;
}
}, 5000); // 5 秒内最多执行一次
- 在页面显示、tab 激活、用户操作后调用
checkNetwork()，而不是自己设 setInterval - 将结果广播给所有关心网络状态的模块（如请求拦截器、UI 提示组件），避免各自重复探测
注意：别对 onLine/offline 事件本身节流
online 和 offline 事件本身触发频率极低，通常整个会话只发生几次。对它们套节流毫无意义，反而可能错过关键状态变更。节流对象必须是你自己写的、可能被高频调用的探测函数，不是浏览器原生事件回调。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
