TypedArray 本身不提供零拷贝，零拷贝依赖 ArrayBuffer 共享内存及 slice()/subarray() 正确使用；new Uint8Array(buffer, offset, length) 是零拷贝，但仅当 buffer 来自 fetch、FileReader 等高效源；手动 new ArrayBuffer 填充数据仍可能引发隐式复制或 GC 压力；浏览器中 fetch 返回的 ArrayBuffer 天然只读驻留，可安全切片；Node.js 中需确保 Buffer.byteOffset === 0 才能安全取 .buffer；对 sliced Buffer 直接用 .buffer 可能越界；复用 ArrayBuffer 应预分配大块内存并按需创建 TypedArray 视图，注意字节对齐；ArrayBuffer 无法局部释放，仅全量无引用后由 GC 回收；Worker 间传递须 postMessage(arrayBuffer, [arrayBuffer]) 转移所有权，否则深拷贝；只能 transfer .buffer，不能 transfer TypedArray 实例；SharedArrayBuffer 需 Atomics 同步且要求跨域隔离；关键难点在于内存共享与隔离边界的准确判断，错误常表现为 detached buffer 异常。
TypedArray 本身不提供“零拷贝”能力，所谓零拷贝是靠 ArrayBuffer 共享内存 + 正确使用 slice() / subarray() 实现的；直接用 Uint8Array.from() 或构造函数传入普通数组，反而会触发完整内存拷贝，彻底失去优势。
为什么 new Uint8Array(buffer, offset, length) 不等于零拷贝？
它确实是零拷贝——但前提是 buffer 本身来自底层高效来源（如 fetch().arrayBuffer()、FileReader.readAsArrayBuffer() 或 SharedArrayBuffer）。如果 buffer 是通过 new ArrayBuffer(size) 手动创建再填充数据，那只是避免了 TypedArray 层的拷贝，原始数据写入过程仍可能有隐式复制或 GC 压力。
- 浏览器中，
fetch()返回的ArrayBuffer天然是只读且内存驻留的，可直接new Float32Array(res.arrayBuffer, 0, 1e6)安全切片 - Node.js 中需用
fs.promises.readFile(path)→ 得到Buffer，再调用buffer.buffer获取底层ArrayBuffer（注意：仅当buffer.byteOffset === 0且未被 sliced 过才安全） - 若对
Buffer调用了.slice()，其.buffer可能指向整块分配内存，此时直接使用会暴露无关数据甚至越界读取
如何安全复用 ArrayBuffer 避免重复分配？
超大文件（如 2GB 点云 BIN）反复解析时，频繁 new ArrayBuffer() 会导致 V8 内存抖动甚至 OOM。正确做法是预分配一块足够大的 ArrayBuffer，用 TypedArray 视图按需映射不同区域。
- 预分配：用
new ArrayBuffer(2 * 1024 * 1024 * 1024)（2GB），比多次小块分配更稳定 - 视图复用：每次处理新数据段时，用
new Float64Array(ab, startOffset, length)创建新视图，不新建 buffer - 注意
startOffset必须是所用 TypedArray 元素字节长度的整数倍（如Float32Array要求 offset % 4 === 0） - 无法释放 ArrayBuffer 中某一段——只能等整个 buffer 不再被任何视图引用后由 GC 回收
Web Worker 中跨线程共享 ArrayBuffer 的关键限制
主线程与 Worker 之间传递 ArrayBuffer 时，必须用 postMessage(arrayBuffer, [arrayBuffer]) 显式转移所有权，否则默认是结构化克隆（即深拷贝）。
- 转移后，原线程的视图立即变为
.byteLength === 0，访问会抛TypeError: Cannot perform %TypedArray%.prototype.set on a detached ArrayBuffer - Worker 收到的是同一块物理内存，可直接构建新视图：
const f32 = new Float32Array(msg.data) - 不能 transfer 普通
TypedArray实例，只能 transfer 其.buffer；transfer 后需重新创建视图 - SharedArrayBuffer 可多线程并发读写，但需配合
Atomics同步，且现代浏览器要求跨域隔离（crossorigin+COOP/COEPheader）
真正难的不是语法，而是判断哪段内存可以共享、哪段必须隔离、哪次 transfer 会意外切断已有视图——这些边界在调试器里看不到，只会在某个随机时间点爆出 detached buffer 错误。
