webassembly共享内存处理超大数组的核心是零拷贝共享地址空间。通过shared memory、typedarray视图、wasm指针操作及边界同步，实现js与wasm共用线性内存，避免堆复制开销。
直接用 WebAssembly 共享内存处理超大型数组容器，核心是绕过 JavaScript 的堆内存复制开销，让 JS 与 Wasm 模块共用同一块底层线性内存。这不是“传数组”，而是“共享地址空间”——数组数据就躺在那块内存里，双方通过偏移量读写，零拷贝。
明确内存归属与初始化方式
超大数组不能靠 new Array(n) 或 JSON.parse 构建，必须由 Wasm 线性内存承载：
- 创建带
shared: true的WebAssembly.Memory（多线程场景必需）或普通Memory（单线程足够） - 初始页数按需设（1 page = 64 KiB），例如处理 100MB 数组：≈ 1563 pages →
initial: 1600 - 用
Uint8Array、Float64Array等视图映射整块 buffer，作为“巨型数组容器”的底层载体
在 Wasm 中定义结构化访问接口
Wasm 模块需导出函数，以指针（即内存偏移）和长度为参数，避免把整个数组当值传递：
- C/Rust 示例中，函数签名类似
process_data(ptr: i32, len: i32)，其中ptr是线性内存中的字节偏移 - 在 C 中用
float* data = (float*)ptr转为指针，直接遍历操作 - 导出
malloc和free辅助函数（或使用 Emscripten 的_malloc/_free），动态分配大数组空间
JS 侧安全高效地读写共享数组
JavaScript 不直接 new 大数组，而是复用内存视图，并注意边界与同步：
- 始终用
new Float32Array(memory.buffer, offset, length)创建视图，而非拷贝 - 写入前确认内存已扩容（
memory.grow(neededPages)），尤其当 Wasm 分配超出初始容量时 - 多线程下使用
SharedArrayBuffer+Atomics控制访问顺序，比如用Atomics.store(control, 0, 1)标记数据就绪 - 避免频繁创建新视图；可复用已有
TypedArray实例，仅调用.set()更新内容
典型流程示例：加载 5000×5000 图像像素矩阵
假设图像为 float32 格式，共 1 亿元素（≈ 381 MiB）：
- JS 创建
Memory({ initial: 6000, maximum: 10000, shared: true }) - 调用 Wasm 的
alloc_image_buffer(width, height)返回起始偏移ptr - JS 用
new Float32Array(memory.buffer, ptr, width * height)获取视图并填入像素 - 调用
process_image(ptr, width, height)，Wasm 原地计算，结果仍存于同一块内存 - JS 直接读取该视图，无需任何 copy 或 decode 步骤
