Shared Worker 实现多窗口表单数据同步

本文深入探讨了如何利用 Shared Worker 实现跨多个浏览器窗口的多步表单数据同步，强调其核心并非依赖底层“原子性”，而是通过将表单状态与变更逻辑完全托管于 Worker 内部、引入序列号（seqId）和步骤校验（fromStep）防止操作错序、结合 IndexedDB 持久化与页面卸载前强制刷盘保障数据不丢失、以及由 Worker 统一发起并管控服务端提交来杜绝竞态与重复请求——真正实现可靠、一致、可恢复的多窗口协同表单体验。

Shared Worker 本身不提供“原子性”保证，但可以作为协调中心，配合明确的状态管理策略和通信约定，实现跨窗口多步表单的数据同步——关键不在“自动原子”，而在“统一入口 + 显式事务语义 + 状态校验”。

必须由 Shared Worker 承载整个表单状态与变更逻辑

不能让每个页面各自维护一份表单数据再靠 Worker 同步。Worker 内需定义唯一可信状态对象（如 formState = { step: 1, data: {} }），所有读写操作都经由它中转：

• 页面发送 { type: "SET_STEP", step: 2, partialData: { name: "Alice" } }，Worker 合并到 formState.data 并更新 step
• 页面发送 { type: "SUBMIT" }，Worker 检查当前 step 是否为终态、data 是否满足必填规则，再统一触发提交请求
• 任何页面调用 { type: "GET_STATE" }，Worker 返回深拷贝后的当前 formState，避免引用污染

用消息类型+序列号防止跨窗口操作错序

用户可能在窗口 A 填第 2 步、窗口 B 同时跳回第 1 步，若仅按接收顺序执行，会导致状态混乱。Worker 应为每次有效变更生成单调递增的 seqId（如用 self.seq = (self.seq || 0) + 1）：

• 页面发变更时附带 seqId 和期望的 fromStep（例如“我当前看到的是 step=2，要提交 step=3 的数据”）
• Worker 收到后比对 formState.step === fromStep，不匹配则拒绝并返回 { type: "CONFLICT", currentStep: formState.step }
• 成功写入后，Worker 向所有端口广播 { type: "STATE_UPDATE", seqId, formState }，各页面可选择丢弃旧 seqId 的消息

关闭/刷新前必须完成本地暂存与最终确认

Shared Worker 在最后一个页面关闭后即销毁，内存状态会丢失。因此不能依赖它持久化表单：

• Worker 每次收到有效变更，立即调用 indexedDB 存储全量 formState（含时间戳和 seqId）
• 新页面连接时，先发 { type: "SYNC_FROM_STORAGE" }，Worker 从 IndexedDB 读最新记录并返回
• 页面卸载前（beforeunload）主动发 { type: "FLUSH" }，Worker 强制写入一次 DB 并响应确认；未收到确认的页面可降级为本地 localStorage 备份

服务端提交必须由 Worker 单点发起并统一处理响应

避免多个窗口同时点击“提交”触发重复请求或竞态错误：

• 只有 Worker 能调用 fetch() 提交表单，页面只发 { type: "REQUEST_SUBMIT" }
• Worker 收到后设 isSubmitting = true，后续请求直接返回 { type: "PENDING" }
• 提交成功后，Worker 清空 formState、清空 IndexedDB，并广播 { type: "SUBMITTED", txId }；失败则广播错误并保留当前状态供重试

理论要掌握，实操不能落！以上关于《Shared Worker 实现多窗口表单数据同步》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！