1.3 典型应用场景

1.3 典型应用场景

本节摘要：选型错误往往不是因为不了解 Wasm 能做什么，而是不清楚它在哪里不划算。本节把典型场景排成一条光谱——从 Web 端计算密集应用到服务端沙箱、边缘函数、跨平台客户端——逐段说明选它的理由、不选它的理由，并用一个完整案例演示判断过程。

概念与目标都清楚了，本节带你去码头实地转一圈：这箱货如今都发往哪些口岸，哪些航线生意兴隆，哪些航线其实不赚钱。判断场景适配性的标尺也一并给你，第七章的实战会反复用到它。

凌晨的部署事故：反着看场景边界

不妨从一次真实的排障现场倒推。某团队把一个纯 CPU 的加解密库从 Node.js 原生插件迁移到 Wasm，上线后大促流量高峰 CPU 反而更吃紧了——排查发现热点不在加解密本身，而在每次请求都把密钥从 JavaScript 拷进线性内存、算完再把结果拷出来的往返上。这个案例的启示值得放在最前面：场景是否适合，取决于计算密度与数据搬运成本之比，而不是"Wasm 很快"四个字。计算密集、数据一次进一次出的场景（编解码、物理模拟、密码学、图像处理），收益立竿见影；频繁小数据互调的场景，搬运成本会吃掉全部收益。

Web 端：计算密度换体验的两类买家

第一类买家是重型生产力工具。图形编辑器、CAD、音视频工作站这类应用的共同点是：核心算法是数年积累的 C/C++ 资产，而用户希望在浏览器里零安装使用。Wasm 让这些资产原样编译上线，而不是用 JavaScript 重写一遍——重写既有正确性风险，也永远追不上原生版本的迭代。

第二类买家是游戏与仿真。游戏引擎的物理、渲染管线是典型的高吞吐低交互代码，Wasm 配合 WebGL/WebGPU 恰好覆盖"引擎内核跑计算、JavaScript 管输入输出"的分工。这类场景对启动时间敏感，流式编译（第五章）与分包加载因此成为标配优化。

以一款浏览器端的矢量协作为例，把判断过程完整走一遍。背景：产品的核心是多人实时编辑复杂矢量文档，文档越大渲染越卡，主线程掉帧明显，团队考虑把渲染内核迁移出 JavaScript。操作：团队没有整体重写，而是把几何运算与光栅化两个模块用 C++ 编译为 Wasm，JavaScript 层保留 DOM 结构与交互逻辑；数据经由共享线性内存传递，每帧只传一次脏区域描述，渲染结果直接写入内存再交给画布显示。结果：大文档下的帧率恢复稳定，主线程有充足预算处理输入事件；由于数据搬运被压到每帧一回，互调开销几乎测不出来。解读：这个迁移划算的根本原因是调用次数少、单次计算量大——每帧一次调用换数毫秒的密集计算，搬运成本占比可忽略；同样的思路若用在"每个图元调一次 wasm 函数"的粒度上，结论会完全反转。变式：若团队日后引入服务端光栅化（瘦客户端方案），同一份内核字节还能复用到边缘节点上跑，一份资产两端受益——这正是第七章"非 Web 部署"要展开的话题。

服务端与边缘：沙箱即产品能力

服务端场景的驱动力不是性能而是隔离。插件系统是最典型的代表：让第三方代码进到你的进程里跑，传统方案要么上独立进程（重、慢、难管理），要么上语言内嵌解释器（弱、慢、生态割裂）。Wasm 提供了第三条路：模块在验证阶段就保证了不越界、不越权，能力由宿主按申报授予，单实例内存开销以百 KB 计，拒绝恶意代码的代价只是丢弃一个实例。电商平台的营销规则引擎、数据库的可加载扩展、消息队列的过滤器插件，都已采用这种模式。

边缘函数是另一大买家。CDN 节点要跑用户上传的代码，冷启动必须压到毫秒级，安全边界必须硬——Wasm 的启动路径短（无需整个进程或容器）、验证前置、资源可控，恰好逐条命中。同一份业务字节在开发机上、在边缘节点上、在用户的浏览器里都能跑，部署单元因此统一。

图 1-B：应用场景光谱——从计算密集到交互密集

跨平台客户端：一份内核，多个外壳

桌面与移动端的跨平台方案里，Wasm 扮演"内核字节"的角色：界面层用各平台原生技术（或 Electron、Tauri 这类壳），核心业务逻辑与算法层编译为 Wasm 复用。相比"每个平台各写一套内核"，这种结构把平台差异压缩在壳层；相比"所有平台都用同一套自绘 UI"，它保留了原生交互体验。音视频处理工具、跨平台数据库引擎（如以 Wasm 形态嵌入应用的 SQLite 构建）、办公套件的文档内核，都是这条路线的常客。

不划算的场景：把丑话说在前面

有几种情况应当直接劝退。重 DOM、重 CSS 的常规业务页面：没有计算热点，Wasm 只会增加包体与一层互调成本。依赖宿主专有能力深度集成的功能：相机、推送、系统分享这类能力反而要靠 JavaScript 桥接，Wasm 帮不上忙。对包体极端敏感的首屏脚本：哪怕 Wasm 字节紧凑，多一份运行时协调代码也是负担。最后是团队工程能力储备：调试符号、性能分析、内存布局优化都需要学习成本，小团队在关键路径上引入新栈，风险常大于收益。

选型快问快答

三个现场频率最高的问题，答案各一句话。问：已有 JavaScript 实现，热点只占两成耗时，值得迁 Wasm 吗？答：先用剖析确认热点集中且数据批量大，是则只迁热点函数、别整体迁移，否则先改算法。问：同一个内核要同时服务浏览器与服务端，工程上怎么组织？答：内核按无系统假设的目标编译成纯计算包，系统交互拆成两层薄外壳——浏览器壳与服务端 WASI 壳——内核一份两端复用。问：模块加载失败会不会拖垮整个页面？答：加载与实例化是异步且可捕获的，把模块初始化放进独立的就绪流程，失败时页面降级到纯 JavaScript 路径即可，第七章的案例会把这套降级模式写成代码。

本节要点回顾

• 判断标尺：计算密度与数据搬运成本之比决定场景适配性，而非笼统的"快"；
• Web 端两类买家：重型生产力工具复用既有 C/C++ 资产，游戏仿真换取稳定帧预算；
• 服务端与边缘：买的不是性能而是验证前置的硬隔离与毫秒级冷启动；
• 跨平台客户端：Wasm 做内核字节、各平台做原生壳，平台差异被压缩到 UI 层；
• 劝退清单：重 DOM 页面、宿主能力密集功能、包体敏感首屏、缺乏调试储备的团队，都该缓行。

看完了码头，第二章该开箱了：二进制格式、WAT 文本、类型与内存，箱内的每节结构都值得亲手拆一遍。