表单提交前需用 navigator.online 结合主动探测（如 head 请求 /healthz）判断断网，因 online 仅反映系统网络状态；须用 abortcontroller 设超时、捕获网络错误而非 http 错误；online/offline 事件不可替代主动探测；离线缓存需序列化表单数据并确保幂等提交。
表单提交前怎么判断用户断网了
浏览器本身不提供「表单提交前检测网络」的内置钩子，得靠 navigator.onLine + 主动探测组合实现。它只是个粗略信号——值为 false 能确定断网，但 true 不代表能连上你的后端。
-
navigator.onLine只反映浏览器是否认为自己在线（比如系统网络开关关闭、飞行模式开启时会变false），不发起真实请求 - 真正可靠的方式是提前发一个轻量
HEAD或GET请求到你自己的 API 域名（如/healthz），超时或 4xx/5xx 就当不可用 - 别用
fetch('https://google.com')这类第三方地址——跨域、被拦截、DNS 慢都会误判，且违反同源策略 - 表单
submit事件里做探测要加event.preventDefault()，等探测完成再手动form.submit()或走 fetch 提交
用 fetch 检测连通性时怎么设超时和错误边界
默认 fetch 没有超时控制，用户 Wi-Fi 卡在 DNS 阶段时会卡住十几秒，表单交互直接冻结。必须自己包一层超时逻辑。
- 用
AbortController控制超时：const controller = new AbortController(); setTimeout(() => controller.abort(), 3000); - 只捕获网络层失败（
TypeError: Failed to fetch）和 abort 错误，不要把 404、500 当作“断网”——那是服务端问题 - 响应状态码检查要显式写：
if (!response.ok) throw new Error(`HTTP ${response.status}`)，否则 503 也会被当成“通” - 避免重复探测：给按钮加 loading 状态，探测中禁用提交；失败后也别自动重试，等用户主动再点一次
监听 online/offline 事件能替代主动探测吗
不能。这两个事件只在浏览器网络栈状态切换时触发（比如拔网线、切热点），对「路由可达但服务宕机」「DNS 解析失败」「HTTPS 证书过期」完全无感。
- 事件触发时机滞后：从断网到
offline事件可能延迟数秒，期间用户仍可点击提交 - 移动端尤其不准：iOS Safari 在后台标签页会暂停事件，Android Chrome 对 Wi-Fi 切移动数据有时不触发
- 适合做辅助提示（比如顶部显示「网络已断开」），但绝不能作为表单拦截的唯一依据
- 如果要用，记得用
window.addEventListener('online', handler)，而不是document—— 事件只在window上冒泡
表单里放「离线缓存提交」功能要注意什么
真要支持离线提交，得配合 localStorage + 后台同步（Background Sync），但后者兼容性差（仅 Chromium 系），实际项目里更常见的是降级处理。
立即学习“前端免费学习笔记（深入）”；
- 别直接存整个
FormData对象——它不可序列化，要用new URLSearchParams(form).toString()或手动提取字段 - 缓存前校验必填字段，否则用户以为提交成功，其实只存了空数据
- 同步逻辑必须幂等：服务端要能识别重复请求（比如用客户端生成的
submission_id做去重） - Chrome 的
backgroundSync需要 HTTPS + Service Worker，且首次触发依赖用户至少一次在线访问，小项目慎用
最常被忽略的一点：探测目标必须是你真实部署的接口路径，不是本地 localhost，也不是开发环境域名——生产环境切 CDN 或反向代理后，连通性结果可能完全不同。
