structuredClone不能深拷贝Proxy对象，会抛出DataCloneError；正确做法是先用toRaw获取target，再structuredClone(target)，最后用原handler重建Proxy。
深拷贝 Proxy 代理对象不能直接用常规方法（比如 structuredClone 或 JSON.parse(JSON.stringify())），因为 Proxy 本身是不可序列化的“黑盒”——它没有可枚举的自有属性，getOwnPropertyNames、keys 等都返回空，且内部 trap 逻辑无法被自动还原。所以处理的核心原则是：不拷贝代理行为本身，而是拷贝其目标对象（target），再按需重建代理。
识别并提取 Proxy 的原始目标
Proxy 对象本身不暴露 target，但可通过以下方式安全获取（前提是未使用 revocable 且未被撤销）：
- 若你创建了该 Proxy，应主动保留对
target的引用（最佳实践） - 若必须从已有 Proxy 推断，可用
Object.getPrototypeOf(proxy) === target配合类型检测辅助判断（不可靠，仅限简单场景） - 注意：
proxy instanceof target.constructor可能成立，但不能反推 target；proxy.toString()通常返回[object Object]，无帮助
避免直接深拷贝 Proxy 实例
任何试图递归遍历或序列化 Proxy 的操作都会失败或静默丢失数据：
-
structuredClone(proxy)→ 抛出DataCloneError（不支持 Proxy） -
JSON.stringify(proxy)→ 返回{}（因无自有可枚举属性） - 手写递归深拷贝中若遇到
typeof obj === 'object'且obj !== null，需额外判断是否为 Proxy：const isProxy = obj => typeof obj === 'object' && obj !== null && typeof obj[Symbol.toStringTag] === 'undefined' && !Array.isArray(obj)（此法不严谨，仅作启发；真正可靠的方式仍是源头保留 target）
推荐做法：深拷贝 target，再重建 Proxy
如果你控制 Proxy 的创建流程，标准解法是：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 保存原始 target（例如存入 WeakMap 或闭包变量）
- 对 target 执行标准深拷贝（如
structuredClone(target)或手写递归） - 用新拷贝的对象 + 原 handler 重新 new Proxy
示例：
const originalTarget = { a: 1, b: { c: 2 } };<br>const handler = { get(t, p) { return t[p]; } };<br>const proxy = new Proxy(originalTarget, handler);<br><br>// ✅ 正确做法<br>const clonedTarget = structuredClone(originalTarget);<br>const newProxy = new Proxy(clonedTarget, handler);
特殊场景：响应式库中的 Proxy 深拷贝
像 Vue 或 Pinia 中的 reactive 对象本质是 Proxy，它们通常提供配套的克隆工具：
- Vue 3 的
toRaw()可获取 reactive 的原始 target，再配合cloneDeep()处理 - Immer 的
produce()内部已绕过 Proxy 直接操作 draft，无需手动解包 - 自研响应式系统建议在 createReactive 时返回 { proxy, raw } 结构，便于后续深拷贝
