WebAssembly 适合用在哪些高性能场景？
WebAssembly 适合放在浏览器里做“JavaScript 能做，但做起来吃力”的计算任务。它不是拿来替代整个前端的技术，更像是一块高性能插件：把图像处理、音视频编解码、游戏物理、加密、科学计算这类热点代码搬进 Wasm，界面、DOM、网络请求仍然交给 JavaScript。
哪些场景最值得用 WebAssembly
图像和视频处理是最典型的场景。比如在线裁剪、滤镜、锐化、格式转换，JavaScript 也能写，但遇到大图、长视频或者批处理时，很容易卡住主线程。FFmpeg.wasm、Squoosh 这类工具的价值就在于复用成熟的 C/C++ 编解码能力，让浏览器本地完成一部分过去必须上传服务器的工作。
游戏和 3D 应用也很适合。Unity、Godot、物理引擎、路径搜索、碰撞检测，都包含大量循环计算。Wasm 负责计算密集部分，WebGL 或 WebGPU 负责渲染，JavaScript 负责输入、状态和页面集成，这种分工比“所有逻辑都写 JS”更稳定。
第三类是加密、压缩、哈希和科学计算。AES、SHA、Zstd、矩阵运算、模型推理这类算法通常已有成熟原生库，直接移植到 Wasm 可以少踩一遍重写算法的坑。尤其是离线工具、隐私敏感工具，把数据留在本地处理还能减少服务端压力。
判断是否该引入 Wasm
一个简单标准是：先用 JavaScript 写出可工作的版本，再用性能数据判断瓶颈。若 Chrome Performance 面板显示时间主要耗在纯计算循环、编码转换或大数组处理上，Wasm 才值得加入。若瓶颈在 DOM 更新、网络等待、接口设计或频繁跨 JS/Wasm 边界调用，引入 Wasm 只会增加复杂度。
emcc image.c -O3 -s WASM=1 -o image.js
这条命令能把 C 代码编译成可被浏览器加载的 Wasm 产物。实际项目里还要关注包体积、初始化时间、浏览器兼容、调试成本，以及是否需要 Worker 避免主线程阻塞。
还有一个容易被忽略的判断维度是部署成本。Wasm 文件通常需要额外的构建、缓存、MIME 配置和加载状态处理，团队也要有人能看懂原语言的报错。对于用户停留时间很短的页面，首包多出几百 KB 可能比计算提速更伤体验。更稳的做法是把 Wasm 做成按需加载模块，只在用户真正进入编辑、转码或分析流程时再初始化。
还要注意浏览器端资源预算。视频转码、模型推理这类任务即使用 Wasm，也会占用 CPU、内存和电量，移动端尤其明显。产品上最好给出进度、取消按钮和文件大小限制，不要让用户误以为页面卡死。若任务超过几分钟，服务端异步处理可能比浏览器硬算更可靠。
追问
WebAssembly 能替代 JavaScript 吗？
不能。Wasm 不能直接操作 DOM，也不擅长写 UI 状态和业务胶水代码。它的优势在计算密集型函数，而 JavaScript 的优势在浏览器 API、事件、组件和生态。真正靠谱的取舍是让 Wasm 做热路径，让 JavaScript 做编排。踩坑点是把大量小函数都放进 Wasm，跨边界调用成本反而可能超过计算收益。
为什么图像、音视频和压缩特别适合 Wasm？
这些任务通常有大块连续数据、明确算法和成熟原生库。Wasm 的线性内存模型很适合处理字节数组，编译器还能做比较激进的优化。边界在于输入输出仍要和 JS 交换数据，文件越大越要减少复制。常见坑是每处理一帧都来回拷贝 ArrayBuffer，最后性能耗在搬数据上。
WebAssembly 一定比 JavaScript 快吗？
不一定。现代 JavaScript 引擎的 JIT 已经很强，普通业务逻辑、字符串处理、小规模数组运算未必输给 Wasm。Wasm 更稳定的是启动后执行性能和接近原生的数值计算能力。取舍点在“热代码是否足够重”，如果只是几十行简单逻辑，构建链、调试和包体积成本不划算。
在生产环境引入 Wasm 要注意什么？
首先要处理加载失败、MIME 类型、CDN 缓存和降级方案，服务器应返回 application/wasm。其次要把初始化做成异步流程，避免页面首屏被 Wasm 下载拖慢。还要给大任务配 Worker，否则 Wasm 在主线程跑同样会卡 UI。边界是 Wasm 只能在沙盒内运行，访问文件、网络、DOM 都需要宿主环境桥接。
哪些场景不建议用 WebAssembly？
表单、列表、路由、权限判断、普通接口聚合都不适合。它们的瓶颈通常不在 CPU，强行使用 Wasm 只会让团队维护两套语言和构建流程。还有一种坑是为了“高性能”把整个应用编译成 Wasm，结果首包巨大、调试困难、SEO 变差。除非是游戏、CAD、编辑器这类强交互重计算产品，否则局部使用更稳。