structuredClone()不可替代JSON.stringify/parse，因其能完整保留Date、RegExp、Map/Set、Blob、循环引用等复杂类型，是PWA离线存储中保障业务上下文保真度的关键深拷贝工具。
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() 是离线上下文“保真度”的守门人——它让业务数据在从内存走向磁盘的过程中，不丢精度、不断链路、不改语义。后续的缓存、同步、恢复，都建立在这个干净副本之上。
