navigator.online仅反映浏览器在线状态，不可单独用于表单提交控制；必须结合fetch探测真实连通性，且需同域、防缓存、设超时、捕获异常。
用 navigator.onLine 判断基础连接状态是否可用
navigator.onLine 是最轻量的检测方式，但它只反映浏览器是否认为自己“在线”——比如 Chrome 在断网后仍可能返回 true（尤其在刚断开、未触发事件时），或在飞行模式下返回 false。它不发请求，也不验证能否连通服务器。
实际使用中必须配合其他手段，不能单独依赖它阻止表单提交：
- 在表单
submit事件里读取navigator.onLine，为真才继续；为假直接event.preventDefault() - 监听
online/offline全局事件，动态更新 UI 状态（如禁用按钮、显示提示） - 注意：该属性初始值可能不准，建议首次检查前加
setTimeout(() => { /* 检查 */ }, 0)让浏览器完成初始化
用 fetch() 发起轻量探测请求验证真实可达性
仅靠 navigator.onLine 不够，真正要确认能否提交表单，得模拟一次与后端通信。推荐用 fetch() 请求一个极简 endpoint（如 /health 或 /ping），响应体只需 200 OK + 空 body。
关键点：
- 设置
cache: 'no-store'防止缓存干扰判断 - 加
signal和超时（如 3s），避免卡死：AbortController控制超时逻辑 - 捕获
TypeError（网络中断）、AbortError（超时）、非 2xx 响应码，统一视为“不可达” - 不要用
GET /api/submit这类真实接口探测——避免副作用或埋点误触发
表单提交前组合校验：先测连通性，再发真实请求
不能把网络检测和表单提交混成一步。正确流程是：用户点击提交 → 触发检测 → 检测通过后才调用 fetch('/api/submit', {...}) 或原生 form.submit()。
实操建议：
- 提交按钮设为
disabled，检测开始时显示 loading 状态，避免重复点击 - 检测失败时，给出明确提示（如“网络异常，请检查连接后重试”），并恢复按钮可点击
- 如果后端支持，可在探测请求头中加
X-Form-Ping: true，便于服务端区分探测流量 - 移动端需额外注意：某些 WebView（如微信内置）对
navigator.onLine支持不稳定，必须依赖fetch探测
兼容性与边界情况处理
navigator.onLine 在 IE9+、现代浏览器均支持；fetch 需要 polyfill（如 whatwg-fetch）以兼容 IE。但更麻烦的是那些“看似在线却无法通信”的场景：
- 公司内网环境：DNS 可解析但网关拦截了外网请求 → 探测地址必须和目标 API 同域或同代理出口
- 防火墙丢弃 ICMP 但放行 HTTP → 不能用
ping，必须走 HTTP(S) 探测 - HTTPS 页面中探测 HTTP 地址会因混合内容被浏览器阻止 → 探测 URL 必须与当前页面协议一致
- 部分安卓 WebView 在后台时暂停 JS 定时器和网络请求 → 检测逻辑需在用户回到前台后重试一次
网络检测不是开关式判断，而是一次有上下文的试探。真正容易被忽略的，是探测目标的选择和超时策略——用错 endpoint 或设太短的 timeout，会让用户频繁看到“网络异常”提示，哪怕他们只是慢了一点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
