structuredClone() 本身不直接参与 PWA 离线存储的“阶段管理”，但它能安全、完整地复制复杂业务数据，为离线存储打下关键基础。真正完成离线存储，仍需配合 IndexedDB 或 Cache API 等持久化机制。
为什么 structuredClone() 在离线上下文保存中不可替代
传统 JSON.stringify/parse 会丢失函数、undefined、Date 对象、RegExp、Map/Set、Blob、TypedArray、循环引用等——而真实业务上下文（如表单草稿、筛选状态、多步骤流程对象、带方法的 ViewModel）往往包含这些。
structuredClone() 是浏览器原生支持的深拷贝 API，能保留：
Date、RegExp、Error 实例的类型和值 Map、Set、WeakMap、WeakSet 的结构与内容 ArrayBuffer、TypedArray、DataView、Blob、File 嵌套对象中的循环引用（不会爆栈） null、undefined、BigInt、Symbol（注意：Symbol 不会被克隆，但不会报错）
在离线流程中何时调用 structuredClone()
它不是独立存储动作，而是发生在“准备写入前”的关键一环：
用户提交但网络失败时：把待发送的请求体（含 FormData 转换后的对象、自定义类实例）先 clone 后存入 IndexedDB pending 表 页面卸载前保存草稿：监听 beforeunload，对当前编辑态的完整 context 对象做 clone，再存入 IDB Service Worker 同步前序列化：在 online 事件中读取 pending 数据时，若需在主线程进一步处理，可用 structuredClone() 安全传给 worker 或其他上下文
搭配 IndexedDB 的典型写入模式
IndexedDB 存储要求数据可结构化克隆（即满足 structuredClone 支持范围），所以你无需额外转换：
const dbRequest = indexedDB.open(‘MyAppDB’, 2);dbRequest.onupgradeneeded = event => { const db = event.target.result; if (!db.objectStoreNames.contains(‘drafts’)) { db.createObjectStore(‘drafts’, { keyPath: ‘id’ }); }};// 保存完整业务上下文（含 Date、Map、嵌套对象等）function saveDraft(context) { const tx = db.transaction(‘drafts’, ‘readwrite’); const store = tx.objectStore(‘drafts’); // ✅ 关键一步：先深拷贝，确保原始对象不被意外修改 const safeCopy = structuredClone(context); // ✅ 直接存入 —— IndexedDB 原生支持该格式 store.put({ id: Date.now(), timestamp: new Date(), data: safeCopy, // 这里是完整上下文副本 status: ‘offline-pending’ });}
注意事项与边界
structuredClone() 不能解决所有问题：
它不处理函数或 class 方法体，只复制属性和内置类型；若需行为复用，应分离逻辑（如将校验函数抽成纯函数，状态单独 clone） 它不自动压缩或分片大数据（如大 Blob），存前需评估 IndexedDB 单条记录大小限制（通常 10–50MB，因浏览器而异） 它不替代缓存策略决策：是否存、存多久、存哪些字段，仍由业务逻辑控制 旧版浏览器（如 Safari 15.4 之前）不支持，需 feature detect 并降级到 lodash.cloneDeep 或手动处理
本质上，structuredClone() 是离线上下文“保真度”的守门人——它让业务数据在从内存走向磁盘的过程中，不丢精度、不断链路、不改语义。后续的缓存、同步、恢复，都建立在这个干净副本之上。
评论(0)