structuredClone() 仅实现安全深拷贝，不具备持久化能力；持久化需结合 IndexedDB 等存储机制，因其为同步内存操作，Service Worker 终止后数据即丢失。
structuredClone() 本身不提供持久化能力，它只是安全深拷贝对象的工具；Service Worker 中真正实现“原始操作序列”的持久化，需要结合 Cache API、IndexedDB 或 localStorage（受限），而 structuredClone() 的核心价值在于：在主线程与 Service Worker 之间、或 Worker 内部跨上下文传递复杂操作数据时，**无损还原原始结构（如 Map、Set、Date、RegExp、嵌套对象/数组等）**，避免 JSON 序列化的丢失问题。
为什么不能只靠 structuredClone() 持久化？
structuredClone() 是同步内存操作，执行完即结束，不写磁盘、不存数据库。它解决的是「克隆」问题，不是「存储」问题。Service Worker 被终止后，所有内存数据（包括 clone 出的对象）都会丢失。因此，必须将 clone 后的数据进一步写入持久化媒介。
典型流程：克隆 → 标准化 → 存储 → 恢复
假设你在主线程收集了一组带时间戳、自定义类实例、Map 参数的操作指令（如 { type: 'UPDATE', payload: new Map([['id', 1], ['value', 'x']]) }），需在 Service Worker 中可靠重建并回放：
- 主线程调用
structuredClone(ops)得到可安全传给 Service Worker 的副本（避免 transferable 限制或循环引用报错） - 通过
postMessage()将克隆结果发送至 Service Worker（注意：仅可传 structured-cloneable 数据，不可传函数、DOM 节点等） - Service Worker 收到后，用
indexedDB存储该序列（推荐）：
– 使用IDBObjectStore.put()直接存整个克隆对象
– 不需手动扁平化，Map/Set/Date 等原生类型会被 IndexedDB 自动序列化保留 - 后续恢复时，从 IndexedDB 读取即得结构完整副本，可直接用于重放逻辑
避坑要点：哪些操作序列适合这样处理？
并非所有操作都适合全量持久化。重点关注以下特征的操作序列：
- 数据驱动型（非 UI 驱动）：如离线表单提交队列、本地缓存更新指令、配置变更日志
- 具备明确重放语义：每个操作可幂等执行，且顺序敏感（如先 create 再 update）
- 体积可控：单次序列不宜超过几 MB，避免阻塞 IDB 事务或触发 SW 超时终止
- 不含不可克隆项：确保原始序列中不含 function、Error、Promise、Window 等无法被 structuredClone() 处理的值
替代 localStorage 的注意事项
虽然 localStorage.setItem('ops', JSON.stringify(structuredClone(ops))) 看似简单，但实际会失败 —— 因为 JSON.stringify() 仍会丢弃 Map/Set/undefined 等；而 structuredClone() + JSON.stringify() 组合并无意义。若坚持用 localStorage，必须自行实现可逆的序列化方案（如把 Map 转成键值对数组），远不如直接走 IndexedDB 简洁可靠。Service Worker 中 localStorage 本身也被部分浏览器禁用或只读，不建议依赖。
本质上，structuredClone() 是你构建可靠离线操作管道的“保真胶水”，真正的持久化要交给 IndexedDB 这样的底层机制。两者配合，才能让原始操作序列在后台线程中既保持结构完整，又跨越生命周期长期可用。
