navigator.onLine仅读取系统网络接口状态，无法验证真实联网能力；true时可能DNS失败或服务器宕机，false时基本确认断网，需配合fetch探测和事件监听实现可靠判断。
navigator.onLine 的判断逻辑和真实限制
navigator.onLine 只是读取浏览器的“网络连接状态”缓存，不是实时探测。它在 Chrome/Firefox 中仅响应系统级网络接口开关（如 Wi-Fi 断开、飞行模式开启），不会触发 HTTP 请求验证服务器可达性。所以你看到 navigator.onLine === false 时，大概率是本地网络已断；但 true 时，API 仍可能 503 或超时。
常见错误现象包括：
- 用户切到地铁隧道后页面仍显示“在线”，同步请求静默失败
- 企业内网环境下 DNS 不通，但
navigator.onLine仍是true - iOS Safari 在后台标签页中长时间不触发
online/offline事件
不要把它当网络健康探针用，只适合做粗粒度状态提示或防重复提交的辅助开关。
监听 online/offline 事件的正确写法
事件必须在页面生命周期早期绑定，且需兼容旧版 Safari（不支持 addEventListener 对 online 的捕获）：
window.addEventListener('online', handleOnline);
window.addEventListener('offline', handleOffline);
<p>// 兜底：首次加载时主动检查
if (navigator.onLine) {
handleOnline();
} else {
handleOffline();
}</p>注意点：
-
handleOnline触发时，不代表服务端已就绪，需配合重试队列 - 事件不冒泡，不能委托；也不能用
ononline="..."内联写法（已被多数浏览器忽略） - Vue/React 组件卸载时务必
removeEventListener，否则可能触发已销毁组件的回调
离线数据同步的触发时机与队列设计
自动同步不该在 online 事件一来就立刻执行，而应：
- 等待 DOM 稳定（用
setTimeout(..., 0)或queueMicrotask） - 检查是否有未完成的同步任务正在运行（避免并发冲突）
- 优先同步高优先级操作（如用户刚提交的表单），再处理日志类低优数据
简单队列示意：
const syncQueue = [];
let isSyncing = false;
<p>function addToSyncQueue(operation) {
syncQueue.push(operation);
if (!isSyncing) triggerSync();
}</p><p>async function triggerSync() {
if (syncQueue.length === 0 || !navigator.onLine) return;
isSyncing = true;
while (syncQueue.length > 0) {
const op = syncQueue.shift();
try {
await fetch('/api/sync', { method: 'POST', body: JSON.stringify(op) });
} catch (e) {
// 失败则插回队首，下次重试
syncQueue.unshift(op);
break;
}
}
isSyncing = false;
}</p>为什么不能只靠 navigator.onLine 做最终同步决策
真正决定“是否该同步”的依据，是业务动作本身是否完成。比如用户点击“保存草稿”，即使当时 navigator.onLine === true，也要等 fetch 成功才清除本地缓存；反之，若请求失败，无论 online 事件是否触发，都应保留数据并标记为 pending。
容易被忽略的地方：
- 同步成功后，要清除 IndexedDB 或 localStorage 中对应记录，否则下次启动还会重推
- 没有用户交互时（如定时上报埋点），
online事件可能被浏览器节流，得配合 visibilitychange 判断页面是否激活 - 多标签页场景下，一个标签页同步成功，其他标签页并不知道，需用
localStorage+storage事件广播状态
离线同步的健壮性，不取决于监听多快，而在于每一步操作是否可逆、可重入、可追溯。
