必须用显式状态机+abortcontroller+幂等键+本地暂存四层协同：idle→submitting→pending→done，超时需abortcontroller主动中断fetch防静默hang，6–8s为宜。
弱网环境下表单提交失败，不是“要不要重试”的问题，而是“根本不知道请求发没发出、到哪一步了、能不能安全重试”的状态失控。必须用显式状态机 + AbortController + 幂等键 + 本地暂存四层协同，缺一不可。
fetch 超时后进不了 catch 怎么办
这是弱网最典型的静默失败：TCP 连接被系统中断，fetch 既不 resolve 也不 reject，UI 卡住。不能只靠 .catch() 捕获错误。
- 必须用
AbortController主动设超时，例如const controller = new AbortController(); setTimeout(() => controller.abort(), 8000) - 超时后
fetch(..., { signal: controller.signal })会抛出AbortError，可被捕获并进入失败分支 - 不要把超时逻辑写在
then外层——它不解决静默 hang，只解决慢响应 - 超时值建议 6–8s：太短误伤弱网用户，太长导致用户以为卡死而反复点击
如何设计一个能落地的状态机
状态机不是画流程图自嗨，它要映射到真实 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 ）才用 <code>setTimeout延迟 2s 后重发，且重试后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 能不能接管表单重试
不能。SW 对 POST 请求的缓存和重试支持极差，且多数采集接口明确禁用 SW 缓存。
-
workbox-strategies的NetworkOnly或StaleWhileRevalidate都不适用于表单提交——前者无重试，后者会缓存失败响应 - SW 的
fetch事件中无法访问页面 DOM 或FormData，拿不到原始表单数据，更没法注入幂等头 - 所有现代框架（React/Vue）的 SPA 场景下，SW 生命周期与页面解耦，页面关闭后 SW 可能仍在运行，导致重试逻辑失控
- 唯一可行路径是：前端 JS 完成序列化 + 存储 + 重试调度，SW 只负责静态资源缓存，对 POST 请求透传不干预
最容易被忽略的是“重试时机”——它不取决于网络恢复，而取决于用户是否还在操作上下文里。document.hidden、visibilitychange、用户点击按钮这三者才是重试触发的真实锚点，而不是 online 事件本身。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
