navigator.online仅反映链路层连通性，无法检测dns故障、代理异常等“假在线”场景；需结合心跳检测（如fetch /healthz）与online/offline事件协同判断真实网络状态。
navigator.onLine 的判断逻辑和真实局限性
navigator.onLine 返回 true 仅表示浏览器认为网络“可用”，比如网线插着、Wi-Fi 已连接、甚至只是开了热点但没连外网——它不发请求，不校验连通性。所以用户看到 true 却打不开接口，或 false 但本地缓存能用，都是正常现象。
- 它依赖操作系统网络栈通知，Chrome/Firefox 在断开物理连接时通常能及时触发
offline事件，但 Wi-Fi 密码错误、代理异常、DNS 拒绝等场景下可能始终返回true - Safari 对
online事件的触发有延迟（尤其从离线切回），不能依赖它立刻更新 UI 状态 - 不要把它当“接口可用性探针”，它只反映链路层连通性粗略信号
监听 online / offline 事件的正确写法
事件必须在 document 或 window 上绑定，且建议在页面加载早期注册（避免错过初始状态）：
function handleOnline() {
console.log('network back');
// 更新 UI：隐藏断网提示、重试队列、恢复轮询等
}
function handleOffline() {
console.log('network lost');
// 显示 toast 或 banner，禁用提交按钮，暂停非关键请求
}
<p>window.addEventListener('online', handleOnline);
window.addEventListener('offline', handleOffline);
</p>
- 不要用
document.addEventListener—— 虽然部分浏览器兼容，但规范明确指定为window对象事件 - 不要依赖首次加载时的
navigator.onLine值做初始化渲染，应结合后续事件驱动状态；例如刚打开页面时是true，但几秒后才真正拿到 DNS 响应，此时仍可能失败 - 避免在事件回调里直接调用耗时操作（如重载整个列表），优先做轻量状态标记，再由其他逻辑响应
为什么必须搭配心跳检测才能真正可靠
单靠 online/offline 无法发现“假在线”：路由器通但上不了网、内网 DNS 故障、CDN 全挂等情况，navigator.onLine 仍为 true。
- 推荐用轻量
fetch('/healthz')（指向一个静态小文件或服务端空响应路由），3–5 秒一次，超时设为 3000ms - 失败连续 2 次才判定为“不可用”，避免偶发抖动误判；恢复则需连续 2 次成功
- 请求头加
cache: 'no-store'和随机 query（如?t=123456），防止 Service Worker 或浏览器缓存返回旧状态 - 心跳响应体无需内容，HTTP 200 即可，减少服务端压力
UI 提示与用户操作的边界处理
断网提示不是越显眼越好，重点在于不干扰已进行的操作，同时提供明确出路：
- 提示文案避免“网络错误”，改用“暂时无法连接服务器”，并附带刷新按钮（不自动 reload）
- 表单草稿、未发送消息必须保留在内存或
localStorage，不要因offline事件清空 - 禁用提交按钮时保留已有输入，用
aria-live="polite"向读屏器说明状态 - 恢复提示不宜过长，2 秒后自动淡出；若用户正在重试请求，应在请求完成后再清除提示，而非单纯等
online事件
真正的难点不在监听事件，而在于如何区分“设备断网”“服务不可达”“请求被拦截”这三类场景——navigator.onLine 只能帮你拦住第一种。
