必须用 AbortController + 主动探测 + 幂等键 + 本地暂存四层兜底，因 navigator.onLine 不反映真实连通性，需同源 HEAD 探测；submit 中需 preventDefault 后同步暂存带重试计数的表单数据；重发应绑定用户交互而非 online 事件；Service Worker 不可缓存 POST；无痕模式需 try/catch 降级内存暂存；幂等键须基于内容哈希。
移动端表单提交时遇到 4G 切 Wi-Fi（或反向切换），请求大概率静默失败——fetch 不进 then 也不进 catch，UI 卡住无反馈。这不是“重试”问题，而是“请求是否真发出去了”的感知缺失。必须用 AbortController + 主动探测 + 幂等键 + 本地暂存四层兜底，缺一不可。
为什么 navigator.onLine 不能信
navigator.onLine 只反映浏览器自身状态（比如是否点了“离线模式”），不是真实网络连通性。实测中：Wi-Fi 已断但路由器未彻底下线、4G 基站切换间隙、DNS 解析超时等场景下，它都返回 true，但 fetch 立刻 hang 住或静默失败。
- 真正可用的判断方式是发一个轻量探测请求，比如
fetch('/favicon.ico', { method: 'HEAD', signal: abortController.signal }) - 探测地址必须同源、静态、无后端逻辑（避免引入额外失败点）
- 必须配
AbortController设超时（建议 3–5s），否则 UI 被阻塞 - 探测失败 ≠ 用户断网，但探测成功 ≠ 表单一定能发出去——它只是“此刻链路大概率通”
submit 事件里怎么安全暂存并阻止跳转
原生 submit 会刷新页面或跳转，所有异步操作（如 fetch、localStorage.setItem）必须在 event.preventDefault() 后同步完成，否则关页前写不进存储。
- 先调
event.preventDefault()，再序列化表单数据：const data = new FormData(formEl)→Object.fromEntries(data) - 生成幂等 key：
const id = crypto.randomUUID() || Date.now().toString(36)，存到localStorage.setItem(`pending-form-${id}`, JSON.stringify({ data, timestamp: Date.now(), retryCount: 0 })) - 注意：不要用
input.files[0]直接存，它在页面重载后失效；需用File.slice()或转为 base64/binary 存（大文件慎用） - localStorage 容量有限（5–10MB），敏感字段（密码、身份证）禁止存
重连后怎么触发重发而不重复提交
监听 window.addEventListener('online') 只能当通知信号，不能直接发请求——此时页面可能还在加载资源、用户没切回来、甚至 fetch 被 abort。
立即学习“前端免费学习笔记（深入）”；
- 真正重发时机应绑定到用户下次主动交互：点击按钮、
visibilitychange回到前台、或启动一个 3s 延迟检查（setTimeout） - 每条暂存记录必须带
retryCount字段，超过 3 次失败就标记为永久失败，避免无限循环 - 重发请求头必须带
X-Request-ID: ${id}，后端据此去重（HTTP 208 或 409 表示已存在） - 成功响应后，必须立刻
localStorage.removeItem()，否则下次打开页面又触发重发
Service Worker 为什么不能接管 POST 请求缓存
SW 对 POST 请求默认不缓存，强行在 fetch 事件里 event.respondWith(cache.match()) 会失败，因为 POST 不满足 HTTP 缓存语义。更危险的是：若 SW 错误地将失败 POST 响应缓存，会导致后续相同表单永远返回假成功。
- 禁用 SW 处理表单提交路径（如
/api/submit），在 SW 的fetch事件中直接return fetch(event.request) - SW 可用于探测请求（如
/health），但不能参与业务提交流 - 移动端 Safari 无痕模式下 localStorage 被禁用，需加
try/catch包裹，并降级为内存暂存（页面存活期内有效）
最易被忽略的点：所有暂存操作必须在 submit 触发的同步上下文中完成，不能依赖 beforeunload；幂等 key 必须基于内容哈希（如 spark-md5 前 2MB），而非仅靠时间戳或随机 ID——否则用户改完再提交，后端无法识别为同一笔请求。
