TypedArray本身不执行缓冲区复制，仅是ArrayBuffer的零开销视图；真正触发复制的是TypedArray.from()、.slice()（非ArrayBuffer.slice）、跨线程未transfer传递等操作。
TypedArray 本身不执行 Buffer Copy，它只是视图
很多人误以为 Uint8Array 或 Float32Array 调用 .slice()、new Uint8Array(otherView) 就是“复制缓冲区”，其实不是。TypedArray 是对 ArrayBuffer 的**只读/可写视图**，创建新视图（哪怕跨类型）几乎零开销——它只改指针偏移和长度，不碰内存内容。
真正触发数据复制的，是以下操作：
-
TypedArray.from()、TypedArray.of()：从普通数组构造，会逐元素拷贝并转换类型 -
.slice()（非ArrayBuffer.slice()）：返回新TypedArray，内部调用ArrayBuffer复制 -
new Uint8Array(source.buffer, offset, length)如果source.buffer是共享的（如SharedArrayBuffer），且目标需独立副本，就必须显式复制 - 跨线程传递（如
postMessage(arrayBuffer, [arrayBuffer])）时，若未使用transferList，则自动深拷贝
异构计算中 Buffer Copy 的真实瓶颈不在 TypedArray 层
在 GPU 计算（WebGL/WebGPU）、NPU（Ascend C）、或 CPU-GPU 协同场景中，TypedArray 通常只用于准备主机端（host）数据。真正的代价来自：
-
gl.bufferData()或device.queue.writeBuffer()：把 TypedArray 数据上传到设备内存 —— 这才是跨总线（PCIe/UMA）复制，耗时取决于数据量与带宽 -
ArrayBuffer.transferToFixedLength()（实验性）或手动new ArrayBuffer(len)+copyWithin：若需预分配+填充，频繁分配小块缓冲区会加剧 GC 压力 - 多视图共用同一
ArrayBuffer但错位访问（如new Int16Array(buf, 2)），虽无复制开销，却可能引发 CPU 缓存行失效（cache line split），在 ARM 或低功耗芯片上影响明显
例如，向 GPU 上传一个 4MB 的 Float32Array，耗时主要由 PCIe 带宽决定（典型值 ~1–5 GB/s），而 TypedArray 构造本身只花纳秒级。
如何低成本做 Buffer Copy —— 避免隐式复制的实操建议
关键原则：让数据停留在同一内存域，复用而非重建。
- 用
ArrayBuffer.slice(start, end)替代TypedArray.slice()：前者返回新ArrayBuffer引用，后者返回新 TypedArray + 新底层 ArrayBuffer（即深拷贝） - 批量上传时，把多个小结构 pack 到单个大
ArrayBuffer，用不同 TypedArray 视图定位字段，避免多次writeBuffer - 需要「读-改-写」时，优先用
DataView配合setFloat32(offset, value, littleEndian)直接修改原缓冲区，而不是构造新 TypedArray - 在 Web Worker 中处理大数组？传
ArrayBuffer时务必加进transferList：worker.postMessage(buf, [buf])，否则默认浅拷贝（即复制全部字节）
容易被忽略的对齐与跨平台陷阱
异构设备（尤其是 NPU、DSP）对内存地址对齐极其敏感。TypedArray 的 byteOffset 必须满足硬件要求，否则复制可能失败或降速。
-
Int32Array视图的byteOffset必须是 4 的倍数；Float64Array要求 8 字节对齐；BigInt64Array同样需 8 字节对齐 - 用
new Uint8Array(buffer, 1)创建偏移为 1 的视图，再转成Int32Array会抛RangeError: start offset of Int32Array should be multiple of 4 - 某些嵌入式 WebGPU 实现（如 Chrome on Android）会静默对齐到 256 字节边界，导致你预期 16KB 的 buffer 实际占用 16384+256 字节 —— 这直接影响 DMA 传输效率
真正卡住性能的，往往不是 TypedArray 用了什么类型，而是你没意识到：它背后那块 ArrayBuffer 正被三个视图同时读、两个线程争抢、还被 GPU 引擎锁着等待同步。
