typedarray 的内存优势在于绕开 js 对象模型：数据连续存放（无间隙）、访问零拷贝（不中转字符串/json）、类型由内存布局直接决定（非运行时检查）。
typedarray（如 uint8array）的内存优势不是“快一点”，而是从底层绕开了 javascript 对象模型的开销。识别它的优势，关键看三点：数据是否连续存放、访问是否零拷贝、类型是否由内存布局直接决定——而不是靠运行时检查。
看内存是否真正连续，而非逻辑连续
普通数组每个元素都是独立对象，带类型标签、引用计数和 GC 跟踪；而 Uint8Array 背后是一整块 ArrayBuffer，所有字节紧挨着排布，没有间隙。你可以用以下方式验证：
- 检查
view.buffer.byteLength和view.length * view.BYTES_PER_ELEMENT是否完全相等——不等说明有 padding 或视图越界 - 用
view.buffer创建另一个类型视图（如new Int32Array(view.buffer)），改一个字节，观察对应整数是否按预期变化（注意字节序） - 避免用
Uint8Array.from([1,2,3])构造——它会先建普通数组再深拷贝，彻底丢失连续性
看有没有发生隐式复制或转换
真正零拷贝的操作，全程不经过字符串、base64、JSON 或普通数组中转。典型信号包括：
- 网络请求直接走
res.arrayBuffer()，而不是res.text()或res.json() - 文件读取用
FileReader.readAsArrayBuffer()，不用readAsDataURL()再atob() - Canvas 像素操作直接用
ctx.getImageData().data（它本就是Uint8ClampedArray），不调用.toDataURL()回传再解析
看是否复用同一 buffer 的多个视图
同一段内存被不同 TypedArray 同时解释，是内存高效最直观的体现：
- 协议头用
new Uint32Array(buffer, 0, 1)[0]读长度，载荷立即用new Uint8Array(buffer, 4, len)切片，没新分配 - 音频处理中，
Float32Array做 FFT 运算，Uint16Array写 WAV 头部字段，共用一个ArrayBuffer - 调用
subarray()返回的新实例，其buffer属性与原视图相同，byteOffset和byteLength只是偏移调整
看是否规避了装箱/拆箱与 GC 压力
TypedArray 元素不进 JS 堆，不触发垃圾回收。可观察两个现象：
- 大量写入时，V8 堆内存（Heap Used）几乎不上升，但
ArrayBuffer占用持续存在 - 用
new Uint32Array(1e6)初始化百万整数，耗时远低于Array(1e6).fill(0)，且后续数值计算无类型转换延迟 - 一旦
view.buffer被 transfer 到 Worker，主线程该视图立刻变为 detached（view.buffer.byteLength === 0），说明内存所有权已移交，无复制痕迹
