WebAssembly线程加速图像卷积需共享内存、Worker分发与SIMD向量化协同：用SharedArrayBuffer零拷贝共享数据，按tile空间分片并行处理，Rust/C++层启用16字节对齐SIMD指令，并控制Worker数量≤8且复用实例。
WebAssembly 线程模型能显著加速大规模图像卷积，但必须结合共享内存、Worker 分发和 SIMD 向量化三者协同，单靠启用线程本身几乎不提升性能。
用 SharedArrayBuffer 实现零拷贝数据共享
主线程与 Worker 之间避免 postMessage 传递像素数据——它会触发完整 ArrayBuffer 复制，开销远超计算本身。正确做法是预先分配 SharedArrayBuffer，并让所有 Worker 通过同一 memory 实例读写：
- 主线程创建
const sharedBuf = new SharedArrayBuffer(width * height * 4) - 初始化 wasm 模块时传入该 buffer：
WebAssembly.instantiate(wasmBytes, { env: { memory: new WebAssembly.Memory({ shared: true, initial: size }) } }) - Worker 中直接使用
new Uint8ClampedArray(sharedBuf)访问像素，无需 set() 或 copyWithin()
按图像区域切分任务并行执行
卷积不具备全局依赖，天然适合空间分片。不建议整图丢给一个 Worker，而应将图像划分为互不重叠的 tile（如 512×512），每个 tile 分配给独立 Worker：
- 对 4096×2160 图像，可切为 8 行 × 4 列 = 32 个 tile
- 每个 Worker 调用 wasm 卷积函数时，只传入该 tile 的起始 offset 和尺寸，避免越界检查
- 主线程用
Promise.all(workerPromises)汇总结果，无需轮询或回调嵌套
在 Rust/C++ 层启用 SIMD 并对齐内存访问
Wasm 线程加速的上限取决于单个 Worker 的吞吐能力。SIMD 是突破瓶颈的关键，但需底层代码配合：
- Rust 中使用
std::arch::wasm32::v128类型，对 RGBA 四通道做并行乘加（如v128.load(&input[i]) * kernel_v） - 确保输入 buffer 地址按 16 字节对齐（
#[repr(align(16))]），否则 SIMD 指令可能降级为标量执行 - 禁用 panic 和边界检查：
rustflags = ["-C", "panic=abort", "-C", "overflow-checks=off"]，减少运行时分支
控制 Worker 数量与生命周期
过多 Worker 不仅无法提升性能，还会因调度竞争和内存争用导致反效果：
- 推荐 Worker 数量 =
Math.min(navigator.hardwareConcurrency || 4, 8)，超过 8 个基本无收益 - 复用 Worker 实例：创建后调用
worker.postMessage({ cmd: 'init' })预热 wasm 模块，后续仅传数据 - 对连续帧处理（如视频滤镜），在 Worker 内部缓存 input/output 视图对象，避免每次新建
Uint8Array
