深拷贝不适合微前端状态隔离，因其仅复制值而无法维持响应式、导致单向断连、丢失特殊类型数据、引发性能问题；真正有效的是JS沙箱隔离与受控通信机制。
深拷贝本身不能直接用于隔离微前端中主子应用的全局状态，它不是解决隔离问题的正确手段，反而可能引入副作用。
为什么深拷贝不适合做状态隔离
主子应用间的状态共享和隔离，核心诉求是可控的读写边界与变更可追踪性。深拷贝只是复制一份值，无法解决以下关键问题：
- 复制后状态失去响应式或监听能力，主应用更新原状态，子应用拿不到通知
- 子应用修改深拷贝后的对象，不会反馈给主应用，造成“单向断连”
- 对嵌套很深或含函数、Symbol、Date、RegExp等特殊类型的对象，普通 JSON.parse(JSON.stringify()) 会丢失数据或报错
- 频繁深拷贝带来性能开销，尤其在高频状态更新场景下不可接受
真正起作用的是沙箱机制 + 受控通信
主流微前端框架（如 qiankun、icestark）不依赖深拷贝，而是通过更底层、更安全的方式实现隔离与通信：
- JS 沙箱隔离：用 Proxy 拦截子应用对 window 的读写，让每个子应用拥有自己的 fakeWindow，天然避免全局变量污染
- 状态托管通信：主应用通过 initGlobalState / set(key, value) 统一管理状态；子应用用 onGlobalStateChange 或 on(key, callback) 订阅变化，只读不直改
- Props 透传只读快照：主应用 mount 子应用时，可传入 { user, permissions } 等轻量只读对象——这一步可以深拷贝（如 structuredClone），但仅限于初始化快照，不是长期隔离方案
什么情况下可谨慎使用深拷贝
仅适用于极少数明确要求“一次性脱钩”的场景，例如：
立即学习“前端免费学习笔记（深入）”；
- 子应用需要一份用户权限配置做本地路由守卫，且确认后续无需响应主应用的权限变更
- 将主应用传来的配置对象转为子应用内部 Vuex/Pinia 的初始 state，且该 store 不再同步外部变更
- 导出当前状态用于日志上报或错误快照，不参与运行时逻辑
此时推荐使用 structuredClone()（现代浏览器支持）或成熟库如 lodash.cloneDeep，而非 JSON 方式。
推荐做法：隔离靠沙箱，通信靠约定
不要试图用深拷贝“切断联系”，而应利用框架能力建立清晰契约：
- 主应用负责状态权威源，统一 set 和广播
- 子应用只订阅、响应、展示，不自行修改共享状态
- 敏感操作（如登出）由主应用触发全局事件或调用子应用暴露的卸载方法
- 样式、DOM、定时器、事件监听等副作用，也需在 unmount 钩子中主动清理
