structuredClone 的 transfer 选项不能在同 Realm 内实现零拷贝转移 ArrayBuffer，仅在跨 Realm（如主线程→Worker）且满足严格条件时可能移交所有权，但不可依赖；真零拷贝须用 postMessage 或 MessageChannel 等原生 transfer 机制。
structuredClone 能不能零拷贝转移 ArrayBuffer？
不能直接靠 structuredClone 的 transfer 选项实现“零拷贝转移所有权”——这是个常见误解。structuredClone 的 transfer 参数只接受 ArrayBuffer 实例，但它不会像 postMessage 那样真正移交所有权；它只是在克隆时把该 ArrayBuffer 排除在序列化之外，并在目标对象中复用同一块底层内存（前提是目标环境支持且未被冻结）。但调用后原 ArrayBuffer 仍可读写，也不会自动变为 detached。
这和 Worker.postMessage(data, [buffer]) 或 MessageChannel 中的 transfer semantics 有本质区别。
哪些场景下 transfer 列表才真起作用？
只有在跨 Realm（比如 iframe、Worker）调用 structuredClone 时，transfer 才可能触发实际所有权移交（依赖引擎实现，目前仅 Chromium 120+ 和 Firefox 125+ 有较完整支持），且仅限于以下条件同时满足：
- 目标是不同 Realm 的全局对象（例如主页面 → Web Worker）
-
ArrayBuffer未被任何TypedArray或DataView持有引用（否则抛DataCloneError） - 浏览器版本足够新（Safari 尚不支持
transfer选项） - 你显式传入的是原始
ArrayBuffer，不是包装后的TypedArray.buffer（虽然等价，但部分旧实现会拒绝）
const buf = new ArrayBuffer(1024);
const arr = new Uint8Array(buf);
<p>// ✅ 正确：传 ArrayBuffer 本身
const cloned = structuredClone({ data: arr }, { transfer: [buf] });</p><p>// ❌ 错误：传 arr.buffer 可能被某些环境拒绝（尽管值相同）
// structuredClone({ data: arr }, { transfer: [arr.buffer] });</p>为什么在同一线程内 transfer 几乎没意义？
同一线程、同一 Realm 内调用 structuredClone 时：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
transfer列表会被忽略（V8 和 SpiderMonkey 当前行为） - 原
ArrayBuffer不会 detach，也不会变只读 - 克隆结果中的
ArrayBuffer是新实例，底层内存仍是深拷贝（除非引擎做了特殊优化，但不可依赖）
换句话说：别指望用 structuredClone 在主线程里“零拷贝”传递大 buffer。真要零拷贝，必须走跨 Realm 通道，比如：
Worker.postMessage(data, [buffer])channel.port1.postMessage(data, [buffer])-
fetch+ReadableStream+transferable（仅限Response.body场景）
容易踩的坑和验证方法
-
structuredClone 后原 ArrayBuffer 仍可用？✅ 是的，除非你手动 buf.detach()
- 克隆后的
ArrayBuffer 是否与原对象共享内存？❌ 同 Realm 下基本不共享；跨 Realm 下取决于引擎，且无法通过 JS 检测（isView、byteLength 看不出）
- 怎么确认 transfer 生效了？唯一可靠方式是检查是否发生
detached：
try {
structuredClone({}, { transfer: [buf] });
console.log('transfer ignored (same realm)');
} catch (e) {
if (e.name === 'DataCloneError' && /detached/.test(e.message)) {
console.log('buf was already detached before clone');
}
}
structuredClone 后原 ArrayBuffer 仍可用？✅ 是的，除非你手动 buf.detach()
ArrayBuffer 是否与原对象共享内存？❌ 同 Realm 下基本不共享；跨 Realm 下取决于引擎，且无法通过 JS 检测（isView、byteLength 看不出）detached：
try {
structuredClone({}, { transfer: [buf] });
console.log('transfer ignored (same realm)');
} catch (e) {
if (e.name === 'DataCloneError' && /detached/.test(e.message)) {
console.log('buf was already detached before clone');
}
}
真正的零拷贝所有权移交，至今仍是跨 Realm 通信的专属能力，structuredClone 的 transfer 只是向这个方向迈出的半步——别把它当 postMessage 的语法糖用。
