深拷贝是微前端状态传递中切断引用的关键环节，需嵌入隔离上下文流程：仅传structuredClone支持的纯数据，禁传函数、DOM等运行时对象；优先用structuredClone做初始化注入，避免运行时反复拷贝；对含逻辑状态应结合闭包受控访问。
在微前端主子应用间传递复杂状态时，深拷贝不是万能钥匙，而是数据隔离链中关键的一环——它只负责切断引用，不负责构建沙箱。真正安全的传递，必须把深拷贝嵌入到隔离上下文的完整流程里。
只传纯数据，不传运行时对象
主应用向子应用注入状态前，先过滤掉所有不可序列化、不可沙箱化的成员：
- 允许传入：普通对象、数组、Date、Map、Set、RegExp、ArrayBuffer（structuredClone 支持的类型）
- 禁止传入：函数、Promise、DOM 节点、window/document、localStorage、undefined、Symbol、闭包变量
- 特别注意：Vue/React 组件实例、带方法的类对象、事件监听器等，即使能深拷贝也不应传入沙箱，它们依赖运行时上下文，拷贝后行为失效甚至引发错误
用 structuredClone 做默认深拷贝通道
现代环境（Chrome 98+、Node.js 18.15+）应优先使用原生 structuredClone，它比 JSON 方案更可靠：
- 自动处理循环引用，避免栈溢出
- 保留 Date、RegExp、Map/Set 等类型语义，不会变成空对象
- 不丢失原型链信息（对普通对象有效），且性能优于手写递归
- 使用前加一层检测：
typeof structuredClone === 'function'，降级时再考虑其他方案
沙箱初始化阶段完成拷贝，而非运行时动态传参
不要在子应用运行中反复调用深拷贝更新上下文，而应在沙箱创建时一次性注入干净副本：
立即学习“Java免费学习笔记（深入）”；
- micro-app 或 qiankun 的沙箱机制（如代理沙箱）本身不自动深拷贝传入的 props；开发者需在
props构造阶段就完成深拷贝 - 示例：
<micro-app name="sub" :data="structuredClone(appState)">，确保子应用接收到的是全新内存空间的数据 - 避免在子应用内部通过 postMessage 或全局事件反复传状态——每次都要重新深拷贝，否则可能把子应用修改后的引用又传回主应用
对含私有逻辑的状态，用闭包+受控访问替代裸拷贝
当状态本身需要封装行为（如带校验规则的表单配置），单纯深拷贝不够，应结合闭包保护：
- 主应用中定义
createProtectedState(initial)，内部用structuredClone初始化私有数据 - 暴露的
get()方法每次返回新拷贝，set()方法写入前也做深拷贝 - 子应用只能读取副本、触发事件通知主应用变更，不能直接修改原始状态
