别再盲目依赖 navigator.onLine，前端网络检测的真实陷阱与解法

开发过程中，你有没有遇到过这种尴尬时刻？用户反馈点击按钮没反应，明明手机连着 Wi-Fi，APP 却显示“网络异常”。打开控制台一看，navigator.onLine 返回的是 true。那一刻真的会让人怀疑人生。

很多人初次接触网络状态检测时，都会直接上手这个属性。它确实方便，但千万别把它当作判断互联网可达性的唯一标准。navigator.onLine 只能告诉你浏览器有没有连接到本地局域网（比如路由器），至于网线是不是断了、运营商服务挂没挂、DNS 有没有解析成功，它是一概不知的。这就好比家里的门锁好了，不代表外面道路畅通无阻。

既然这个属性不靠谱，正确的姿势是什么？核心思路其实就两点：监听状态变化加上主动探测心跳。

监听层面，我们需要注册 window.addEventListener('online', ...) 和 offline 事件。这在切出页面或开关飞行模式时非常有用。不过要注意，这两个事件的触发时机在不同浏览器上存在差异，iOS Safari 有时甚至会延迟触发。所以单纯靠事件监听，依然不够稳健。

想要知道真正的“互联网连通性”，必须发起一个轻量级的网络请求。推荐做法是配置一个极短的头部请求（HEAD）作为心跳包，目标可以是服务器上的一个空接口或者简单的图片资源。如果请求超时或失败，哪怕 onLine 是 true，也要判定为网络不可用。

下面是一个相对稳妥的检测逻辑骨架，你可以参考：

function checkNetworkStatus() {
  if (!navigator.onLine) return 'offline';

  // 发起轻量探测
  return fetch('/health-check', { method: 'HEAD', mode: 'no-cors' })
    .then(() => 'online')
    .catch(() => 'unreachable');
}

这里有个细节值得注意，对于单页应用（SPA），如果在页面加载初期网络就不通，可能会影响后续路由跳转或数据缓存。建议在前端架构层封装一个全局的“网络状态管理器”，一旦检测到断网，立即锁定操作入口，并在 UI 上给出明确的提示文案，而不是让用户干等着转圈。

具体落地时，可以考虑在顶部增加一个全局 Toast 或横幅条。当切换到离线模式，提示“网络连接已断开，正在尝试恢复”；恢复上线后，自动静默刷新数据。这种交互细节能极大地减少用户的焦虑感。

另外，移动端场景下还要考虑网络切换的问题。用户从 Wi-Fi 切到 4G，有时候 IP 地址变了会导致会话失效。这时候光看网络连上了不行，还得配合后端 Session 刷新机制。同时，注意不要频繁轮询检测接口，否则反而会增加设备耗电量，甚至被防火墙拦截。合理的做法是结合 visibilitychange 事件，只在用户回到前台时才重新校验状态。

归根结底，做网络检测不是为了展示代码能力，而是为了优化用户体验。与其纠结于 onLine 到底是真还是假，不如设计一套容错机制：允许重试、展示离线缓存内容、或者引导用户检查设置。当你能在弱网环境下让产品依然保持流畅，才是真正的技术价值所在。

下次再看到 navigator.onLine，记得多留个心眼，毕竟用户的耐心比想象中要少得多。