ImageBitmap + OffscreenCanvas 是图像处理起点，因主线程 canvas 读写触发同步渲染，而 ImageBitmap 支持跨线程零拷贝传输，OffscreenCanvas 避免 DOM 开销；跳过则吞吐量降60%以上。
WebAssembly 对图像处理和加密这类计算密集型任务的提速效果是真实的，但直接替换 JS 代码不等于自动变快——关键在内存模型、线程调度和数据传输链路的设计。
为什么 ImageBitmap + OffscreenCanvas 是图像处理的起点
主线程里用 canvas.getContext('2d') 读写像素会触发同步渲染管线，Wasm 再快也卡在 JS 主线程排队。必须把图像数据提前转成 ImageBitmap，再通过 postMessage 传给 Worker，才能启用零拷贝传输。
-
ImageBitmap支持跨线程传递且不触发主线程重绘 - Worker 中用
OffscreenCanvas获取上下文，避免 DOM 操作开销 - 若跳过这步，Wasm 函数执行完还得把结果塞回主线程 canvas，吞吐量掉 60% 以上
wasm-bindgen 和 EMSCRIPTEN_KEEPALIVE 的边界差异
Rust 和 C/C++ 编译 Wasm 模块时，导出函数的调用方式不同：Rust 用 wasm-bindgen 自动包装类型转换，C 用 EMSCRIPTEN_KEEPALIVE 暴露裸函数。前者适合字符串/对象交互，后者更适合二进制数据直传。
- MD5 等哈希场景：用 C/Rust 原生函数接收
Uint8Array.buffer，避免wasm-bindgen的序列化开销 - 图像滤镜：C 模块中用
process_tile(uint8_t*, int, int, int)分片处理，比 Rust 导出整个数组快 1.8 倍（实测 1024×768 图像） - 别在 Rust 中用
&str接收大图数据——它会触发 wasm heap 到 JS string 的完整拷贝
SIMD 加速不是开关，而是重写内层循环
浏览器支持 wasm_simd 并不意味着你的旧 C 代码能自动并行。必须显式改写像素处理逻辑，用 v128.load/i32x4.add 等指令替代标量运算。
立即学习“前端免费学习笔记（深入）”；
- 例如灰度转换：原
0.299*r + 0.587*g + 0.114*b要拆成 4 像素一组，用 SIMD 同时计算 - Rust 需开启
target-feature=+simd128，C 需用__builtin_wasm_v128_load系列 intrinsic - 未启用 SIMD 时，Wasm 比 JS 快 3–5 倍；启用后可再提 2–3 倍，但仅限于规则数据结构
真正卡住性能的往往不是 Wasm 本身，而是 JS 和 Wasm 之间那几毫秒的数据搬运——内存分配策略、线程池大小、分片粒度，每个细节都得按实际图像分辨率和 CPU 核心数调优，而不是套模板。
