structuredClone 无法克隆 Promise，因其本质是带副作用的异步行为封装，内部状态和执行上下文不可序列化；应改用函数封装、结果拷贝或三态字段等合理替代方案。
structuredClone 本身不支持 Promise，这是它的硬性限制，不是“没写好”或“能绕过”的问题。Promise 是一个运行时状态机，内部包含 pending/fulfilled/rejected 状态、微任务队列绑定、resolve/reject 句柄等不可序列化的执行上下文，任何结构化克隆算法（包括 structuredClone、MessageChannel、JSON 序列化）都无法真正复制它。
为什么 Promise 无法被深拷贝
关键在于 Promise 的本质不是纯数据，而是带副作用的异步行为封装：
- 其内部 [[PromiseState]] 和 [[PromiseResult]] 是私有不可访问字段，无法读取或重建
- resolve/reject 函数绑定在创建时的执行环境，克隆后无法复现相同调度逻辑
- 已 resolve 的 Promise 与未 resolve 的 Promise 表现一致，但 clone 后的新对象既不是 pending，也无法触发 then/catch —— 它根本就不是 Promise 实例
- 即使强行 new Promise((r) => r(originalResult))，也只是新建一个等价结果的 Promise，不是原实例的副本，且丢失了原始的链式调用上下文
实际业务中该怎么做
不要尝试“克隆 Promise”，而应根据用途选择合理替代方案：
-
若需复用异步逻辑：把 Promise 创建逻辑封装为函数，每次调用生成新实例
例如：const createFetch = () => fetch('/api/data')，而不是试图拷贝fetch('/api/data')的返回值 -
若需保存 Promise 结果用于后续使用：等待其 settled 后，用
structuredClone拷贝value或reason（前提是结果本身可克隆） - 若在状态管理中遇到 Promise 字段：设计上应避免将 Promise 存入可克隆的数据结构（如 Redux state、Vue reactive 对象）。改用 loading/pending + data/error 三态字段代替
- 若调试或日志需要“记录”Promise：只记录其构造信息（如 URL、method、参数），而非 Promise 实例本身
警惕那些看似可行的“伪克隆”陷阱
以下写法看似复制了 Promise，实则无效或危险：
-
structuredClone(promise)→ 直接抛DataCloneError -
JSON.parse(JSON.stringify(promise))→ 返回空对象{}，且丢失全部语义 -
Object.assign({}, promise)或展开运算符 → 只拷贝可枚举属性（通常为空），不复制原型方法（then、catch全失效） -
new Promise(r => r(promise))→ 不是克隆，是链式转发；原 Promise 失败仍会连带影响，且无法控制新 Promise 的 resolve 时机
Promise 不是数据，它是动作。想“拷贝动作”，不如重新发起动作。这个认知偏差才是真正的死结所在。
