弱网环境下表单提交的载荷重试机制与状态机设计

弱网环境下的表单提交，最令人困扰的往往并非“是否重试”，而是“请求究竟处于什么状态：是否已发出、能否安全重试”。这种状态失控才是真正的难点。解决方案也很明确：必须构建显式状态机 + AbortController + 幂等键 + 本地暂存这四层协同机制，缺一不可。

fetch 超时后进不了 catch 怎么办

先提一个最易踩的坑：TCP连接被系统中断后，fetch既不resolve也不reject，UI直接卡死。不能指望.catch()一个方法就能处理所有异常。

• 必须用 AbortController 主动设置超时。例如 const controller = new AbortController(); setTimeout(() => controller.abort(), 8000)，超时后fetch会抛出AbortError，能被捕获并进入失败分支。
• 超时逻辑不要写在then外层——它只处理慢响应，无法解决静默挂起。
• 超时值一般建议6–8秒：太短易误伤弱网用户，太长则让用户感觉卡顿，进而反复点击，加剧问题。

如何设计一个能落地的状态机

状态机不是画完流程图就完事，它需要直接映射到真实的DOM行为和存储操作。核心状态仅四个：idle → submitting → pending → done。每个状态必须有明确的副作用，不能模棱两可。

• idle：按钮可点击，localStorage中无对应的pending key，表单尚未序列化。
• submitting：按钮立即disabled = true，同步调用event.preventDefault()，生成幂等key（如crypto.randomUUID()），将FormData转为对象存入localStorage.setItem(`pending-form-${key}`, JSON.stringify({...}))。
• pending：请求已发出但未返回。此时若页面刷新或切换后台，依靠localStorage恢复状态。监听window.addEventListener('online')仅作为信号，不自动重发。
• done：成功则清除localStorage中对应项；失败且满足重试条件（navigator.onLine && document.hidden === false && retryCount < 3），才用setTimeout延迟2秒后重发，同时retryCount++。

幂等 key 为什么不能只用时间戳或随机数

单纯用Date.now()或Math.random()生成key，同一表单多次提交会被服务端当作不同请求，导致重复扣款、重复注册等严重问题。

• 真正安全的幂等key需绑定内容：对表单字段做轻量哈希，如sha256(JSON.stringify(sortedEntries))，再拼接时间戳防止碰撞。
• 若无法引入crypto库，可退而求其次：用crypto.randomUUID() + 表单action URL + 所有非空字段名排序后的字符串，三者拼接后取前16字符。
• 切勿将input.files[0].name这类易变字段混入哈希——文件名用户可随意更改，幂等性将被破坏。
• 服务端必须校验该key是否已存在，若存在则直接返回上次结果，不执行业务逻辑。

Service Worker 能不能接管表单重试

不能。Service Worker对POST请求的缓存和重试支持非常有限，且多数采集接口明确禁用SW缓存。

• workbox-strategies中的NetworkOnly或StaleWhileRevalidate均不适用于表单提交——前者无重试机制，后者会缓存失败响应。
• SW的fetch事件中无法获取页面DOM或FormData，更无法注入幂等头。
• 在React/Vue这类SPA场景下，SW生命周期与页面解耦，页面关闭后SW仍可能运行，重试逻辑极易失控。
• 唯一可靠的路径是：前端JS完成序列化 + 存储 + 重试调度，SW只负责静态资源缓存，对POST请求直接透传，不予干预。

最后想提醒的是，重试时机最容易被忽略——它不取决于网络恢复，而取决于用户是否仍在操作上下文中。document.hidden、visibilitychange、用户点击按钮，这三者才是重试触发的真实锚点，而不是online事件本身。