ArrayBuffer.transfer 后原缓冲区为什么变成不可用

我第一次遇到这个问题，是把一段二进制数据交给下一个处理环节后，回头读取原来的 ArrayBuffer，发现 byteLength 变成了 0，连原先创建的 Uint8Array 视图也不能再当作数据入口。看起来像变量被清空了，实际发生的是一次明确的所有权转移。

ArrayBuffer.transfer() 会返回一个新的 ArrayBuffer，并让原 ArrayBuffer 进入 detached 状态。原变量仍然指向那个对象，但它已经失去底层字节；后续代码必须改用 transfer() 的返回值。

本文只围绕这个现象排查：为什么旧缓冲区不可用、怎样用 detached 和 byteLength 观察状态，以及 transfer(newByteLength) 在缩短和扩大时分别保留什么。这里不展开 Worker 消息传递或 SharedArrayBuffer。

原变量还在，为什么读不到原来的字节

transfer() 的关键不是普通赋值，也不是把一个对象变量改名。它创建一个新的 ArrayBuffer，让新对象接管原来的字节，并把旧对象标记为 detached。所以这两件事可以同时成立：旧变量仍然存在，旧变量却不能再访问原来的内存。

可以把它理解成“对象身份没有消失，底层存储的使用权已经交接”。这样解释 byteLength 变成 0 就不奇怪了：旧对象没有可供 JavaScript 继续访问的字节范围，新对象才是后续读取入口。

用 detached 和 byteLength 观察现场

排查时不要只盯着某个业务变量。把转移前的缓冲区、转移后返回的新缓冲区和旧视图同时列出来，现象就容易定位：旧缓冲区的 detached 为 true，旧缓冲区的 byteLength 为 0，而新缓冲区仍保留原来的数据长度。

const source = new ArrayBuffer(8);
const sourceView = new Uint8Array(source);
sourceView[0] = 42; // 先写入一个示例字节，便于观察所有权交接

const target = source.transfer();

console.log(source.detached); // true：旧对象已脱离底层存储
console.log(source.byteLength); // 0：旧对象不再暴露字节范围
console.log(sourceView.byteLength); // 0：关联视图也失去可用范围
console.log(target.byteLength); // 8：新对象成为后续读取入口

这里最容易误判的是第一行：source 没有变成 null，也没有从作用域消失。它只是变成了一个仍可被引用、但已经 detached 的对象。若运行环境支持 detached 属性，可以在转移前后直接读取它；若只观察 byteLength，也能把“旧对象不可用”与“新对象仍有数据”区分开。

TypedArray 视图为什么也跟着失效

Uint8Array、Int32Array 和 DataView 不是独立保存一份字节，它们只是把一段 ArrayBuffer 暴露成特定的访问方式。sourceView 仍然是一个 JavaScript 对象，但它依赖的底层缓冲区已经 detached，因此视图不能绕过所有权边界重新拿回数据。

这也是为什么“我已经提前保存了视图”不是修复方案。保存视图只保存了旧对象的访问窗口，没有复制字节。需要继续处理数据时，应当在转移前复制出独立数据，或者把后续流程改成接收并使用 target。

function handoff(buffer) {
    const next = buffer.transfer();

    // transfer 后不要继续把旧 buffer 或旧 view 传给下游。
    return next;
}

let buffer = new ArrayBuffer(16);
const view = new Uint8Array(buffer);
view[3] = 7; // 示例业务字节写入原缓冲区

buffer = handoff(buffer); // 用返回值覆盖旧引用
const nextView = new Uint8Array(buffer); // 从新对象重新创建视图
console.log(nextView[3]); // 7：读取入口已经切换到新缓冲区

这段代码的重点不是函数名，而是赋值方向：buffer = buffer.transfer() 让变量立即指向新对象。旧的 view 不应再参与后续读写；如果业务同时保存了多个旧引用，也要一起清理或改为传递新对象。

newByteLength 决定保留、丢弃还是补零

不传参数时，新缓冲区保持原来的长度；传入 newByteLength 后，结果由目标长度决定。目标长度小于原长度时，超出部分会被丢弃；目标长度大于原长度时，新增区域会填充零。这不是“把容量标记改大”，而是得到一个具有新字节范围的新对象。

const original = new ArrayBuffer(8);
const bytes = new Uint8Array(original);
bytes[1] = 2;
bytes[7] = 4; // 记录尾部字节，观察缩短时它会被丢弃

const shorter = original.transfer(4);
const shorterView = new Uint8Array(shorter);
console.log(shorter.byteLength); // 4：只保留前四个字节

const larger = shorter.transfer(8);
const largerView = new Uint8Array(larger);
console.log(larger.byteLength); // 8：新增区域以零填充
console.log(largerView[7]); // 0：扩大不会恢复已被截断的旧字节

这个例子里，shorter 已经丢掉原来索引 4 到 7 的内容，后面再把它扩大到 8 字节，也只能得到零填充区域。若数据格式有尾部校验、分片长度或偏移量，缩短前要先确认被裁掉的字节确实不再需要。

可调整缓冲区与固定长度结果怎么选

如果原来的 ArrayBuffer 是可调整的，新返回对象会保留这种可调整属性，并沿用原来的 maxByteLength 限制。此时 newByteLength 不能超过 maxByteLength，否则会抛出 RangeError。目标长度合法，但原对象已经 detached 时，调用也会因状态不对而抛出 TypeError。

const resizable = new ArrayBuffer(8, { maxByteLength: 16 });

// 目标长度不能超过创建时设定的 maxByteLength。
const next = resizable.transfer(12);
console.log(next.resizable); // true：可调整属性被保留
console.log(next.maxByteLength); // 16：上限不会在 transfer 时放大

// 如果业务交接后不允许继续调整长度，可选择固定长度结果。
const fixed = next.transferToFixedLength();
console.log(fixed.resizable); // false：得到不可调整的 ArrayBuffer

选择可以按数据生命周期来判断：后续还要根据输入量调整容量，就使用 transfer() 并保留可调整属性；交接后只允许读取固定字节范围，就考虑 transferToFixedLength()。固定长度方法同样会让调用它的原对象 detached。

把修复落到一次所有权交接

我现在处理这类代码，会把 transfer() 看成一个明确的交接点，并遵守三条规则。第一，调用结果必须被命名、返回或重新赋给主变量；第二，旧的 ArrayBuffer 和 TypedArray 视图从交接点后不再进入下游；第三，调试日志优先打印 detached、byteLength 和新对象长度，而不是只打印变量是否存在。

一句话总结：transfer() 不是“复制后两个对象都能继续用”，而是“把底层字节的使用权交给新对象”。旧变量还在，只是它已经没有可访问的字节；只要把返回值作为新的唯一入口，detached 问题就不会继续扩散。

常见问题

transfer() 会不会让原 ArrayBuffer 变量变成 null？ 不会。变量仍引用原对象，但原对象进入 detached 状态，byteLength 变成 0。

提前保存 Uint8Array 视图能避免失效吗？ 不能。视图依赖原缓冲区的底层字节，transfer 后应从新对象重新创建视图。

newByteLength 比原长度大时，原尾部会自动复制过去吗？ 不会。超过原长度的新增区域以零填充；如果原数据已经在更短的 transfer 中被丢弃，后续扩大也不会恢复。

transfer() 和 transferToFixedLength() 怎么选？ 前者保留可调整属性，后者返回固定长度的 ArrayBuffer；选择取决于交接后的数据是否还需要调整容量。