登录
WASM 替代服务端的场景探索
WASM 替代服务端的场景探索：视频处理、加密、数据分析，3 个方向的实战验证
你有没有想过，前端直接处理一个 200MB 的视频文件，不经过服务器？两年前我会觉得这是异想天开，但最近在项目里用 WebAssembly 把三个原本必须走服务端的重计算场景搬到了浏览器里跑，结果不但跑通了，某些场景下体验比服务端还好。这篇文章不是 WASM 入门科普，而是聚焦三个具体方向——视频处理、加密运算、数据分析——逐个拆解：哪些场景真的适合用 WASM 替代服务端，哪些是伪命题，以及我踩过的那些坑。
二、视频处理：最直观的收益场景
2.1 痛点在哪
我们的 B 端系统有个视频裁剪功能，用户上传一段会议录像，截取其中 5 分钟片段。原来的流程是：前端上传到 OSS → 服务端拉下来用 FFmpeg 裁剪 → 结果传回 OSS → 前端拿下载链接。一个 500MB 的视频，光上传就要 2 分钟（按 4MB/s 算），服务端处理 30 秒，下载又 1 分钟。
2.2 WASM 方案：ffmpeg.wasm
ffmpeg.wasm 是 FFmpeg 编译到 WebAssembly 的版本，核心能力和原生 FFmpeg 基本一致。关键代码长这样：
import { FFmpeg } from '@ffmpeg/ffmpeg';
import { fetchFile, toBlobURL } from '@ffmpeg/util';
const ffmpeg = new FFmpeg();
// 加载 WASM 核心，这一步大概要下载 25MB 左右的 wasm 文件
await ffmpeg.load({
coreURL: await toBlobURL('/ffmpeg-core.js', 'text/javascript'),
wasmURL: await toBlobURL('/ffmpeg-core.wasm', 'application/wasm'),
});
// 把用户选择的视频文件写入虚拟文件系统
await ffmpeg.writeFile('input.mp4', await fetchFile(videoFile));
// 执行裁剪：从第 60 秒开始，截取 300 秒
await ffmpeg.exec([
'-i', 'input.mp4',
'-ss', '60',
'-t', '300',
'-c', 'copy', // 关键：不重新编码，直接拷贝流
'output.mp4'
]);
const data = await ffmpeg.readFile('output.mp4');
const blob = new Blob([data], { type: 'video/mp4' });
这里有个关键点：-c copy 参数。它表示不重新编码，只做流拷贝。视频裁剪、拼接这类不需要重新编码的操作，WASM 的性能完全够用。但如果你要做转码（比如 H.265 转 H.264），浏览器里跑 WASM 会比服务端慢 5-10 倍，这种场景不建议迁移。
2.3 踩坑记录
**坑一：SharedArrayBuffer 的安全限制。
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
我们在 Nginx 加了这两个头之后，页面里嵌入的第三方统计脚本全挂了，因为 require-corp 会拦截没有 Cross-Origin-Resource-Policy 头的跨域资源。最后的方案是把 ffmpeg 处理逻辑放到一个单独的 iframe 里，主页面不受影响。排查这个问题花了大半天。
坑二：内存限制。 浏览器里 WASM 的内存上限通常是 2GB-4GB。处理超过 1GB 的视频文件时，虚拟文件系统会把整个文件加载到内存，很容易 OOM。我们的解法是对大文件先在 JS 层做分片，每次只处理一个分片。
2.4 效果对比
同一个 500MB 视频裁剪 5 分钟片段：| 指标 | 服务端方案 | WASM 方案 | |------|-----------|----------| | 总耗时 | 3 分 30 秒 | 45 秒 | | 服务器带宽消耗 | 1GB（上传+下载） | 0 | | 用户体验 | 上传等待+轮询结果 | 本地实时进度条 | | 月均成本 | ~5000 元 | 0 |
45 秒主要花在读取本地文件到内存上，裁剪本身 -c copy 模式下只要几秒。
三、加密运算：隐私合规的刚需场景
3.1 痛点在哪
去年接了一个医疗数据平台的项目，有个硬性要求：患者的身份证号、手机号等敏感字段，在离开浏览器之前必须完成加密，服务端只存密文。甲方的安全团队原话是："明文不能出浏览器"。
JavaScript 本身有 Web Crypto API，但它只支持标准算法（AES、RSA、SHA 系列）。
用纯 JS 实现 SM2？可以是可以，npm 上有 sm-crypto 这个包，但性能非常拉胯。我们测过，批量加密 1000 条记录（每条包含 3 个敏感字段），纯 JS 版要 8.2 秒，用户能明显感知到页面卡顿。
3.2 WASM 方案：C 语言国密库编译到 WASM
我们选了开源的 GmSSL（C 语言实现），用 Emscripten 编译成 WASM 模块。封装后的调用接口大概是这样：
// wasm_sm_crypto.js —— 封装层
import initWasm from './gmssl.wasm.js';
let wasmInstance = null;
export async function init() {
wasmInstance = await initWasm();
}
export function sm4Encrypt(plaintext, key) {
// 把 JS 字符串写入 WASM 线性内存
const encoder = new TextEncoder();
const data = encoder.encode(plaintext);
const keyBytes = hexToBytes(key);
const dataPtr = wasmInstance._malloc(data.length);
const keyPtr = wasmInstance._malloc(16);
const outPtr = wasmInstance._malloc(data.length + 16); // 补齐 padding
wasmInstance.HEAPU8.set(data, dataPtr);
wasmInstance.HEAPU8.set(keyBytes, keyPtr);
// 调用 C 函数
const outLen = wasmInstance._sm4_cbc_encrypt(
dataPtr, data.length,
keyPtr,
outPtr
);
const result = new Uint8Array(
wasmInstance.HEAPU8.buffer, outPtr, outLen
);
const encrypted = bytesToHex(result);
// 释放内存——这一步千万别忘
wasmInstance._free(dataPtr);
wasmInstance._free(keyPtr);
wasmInstance._free(outPtr);
return encrypted;
}
这段代码有个容易踩的坑：手动内存管理。WASM 没有 GC，_malloc 了必须 _free，不然内存泄漏。我们早期忘了释放 outPtr，跑了一会儿就 OOM 崩了。后来统一封装了一个 withMemory 的 helper 函数，类似 Go 的 defer，确保作用域结束自动释放。
3.3 性能数据
批量加密 1000 条记录（每条 3 个字段，SM4-CBC 模式），三个方案对比：
纯 JS（sm-crypto） ：8200ms
WASM（GmSSL 编译） ：620ms
服务端（Go + GmSSL） ：45ms + 网络 RTT 约 200ms ≈ 245ms
WASM 比纯 JS 快了 13 倍。虽然绝对性能不如服务端，但 620ms 的延迟在用户提交表单时完全可以接受，而且满足了"明文不出浏览器"的合规要求。
四、数据分析：最容易被低估的方向
4.1 痛点在哪
我们有个运营后台，核心功能是让运营同事导入 Excel（通常 10 万-50 万行），做筛选、分组统计、透视表这些操作。原来的方案是把 Excel 传到服务端，用 Python Pandas 处理完把结果返回。问题有两个：一是每次改个筛选条件就要重新请求服务端，交互延迟很明显（平均 3-4 秒）；二是运营同事经常在处理还没确认之前反复调整条件，十几次请求打到后端，白白浪费计算资源。
4.2 WASM 方案：DuckDB-WASM
DuckDB 是一个嵌入式分析型数据库（你可以理解为分析场景的 SQLite），它有官方的 WASM 版本，可以直接在浏览器里跑 SQL。
import * as duckdb from '@duckdb/duckdb-wasm';
// 初始化
const JSDELIVR_BUNDLES = duckdb.getJsDelivrBundles();
const bundle = await duckdb.selectBundle(JSDELIVR_BUNDLES);
const worker = new Worker(bundle.mainWorker);
const logger = new duckdb.ConsoleLogger();
const db = new duckdb.AsyncDuckDB(logger, worker);
await db.instantiate(bundle.mainModule, bundle.pthreadWorker);
const conn = await db.connect();
// 直接把前端拿到的 Excel 转成的 CSV/Parquet 注册为表
await db.registerFileBuffer(
'sales.parquet',
new Uint8Array(parquetBuffer)
);
// 然后就能直接写 SQL 了
const result = await conn.query(`
SELECT
region,
product_category,
SUM(amount) as total_sales,
COUNT(*) as order_count
FROM 'sales.parquet'
WHERE order_date >= '2025-01-01'
GROUP BY region, product_category
ORDER BY total_sales DESC
`);
这段代码的亮点在于：你在浏览器里获得了一个完整的 SQL 引擎。
4.3 为什么不用纯 JS 方案
你可能会问，直接用 JS 数组操作 filter、reduce 不行吗？10 万行数据在 JS 里 reduce 一下也不慢。
小数据量确实可以。但当数据到了 30 万行以上，差距就出来了。DuckDB 底层是列式存储 + 向量化执行引擎，这两个东西是专门为分析型查询设计的。打个比方：JS 数组遍历是逐行扫描，像你拿着清单一行一行找；DuckDB 的列式引擎是直接把"金额"那一列拎出来批量求和，跳过了所有不相关的列。我们在 30 万行、12 列的数据集上做了对比测试——分组聚合（GROUP BY 2 列，SUM 1 列）：
JS Array.reduce() ：1850ms
Lodash _.groupBy() ：2100ms
DuckDB-WASM SQL ：180ms
服务端 Pandas ：95ms + 网络 RTT 800ms ≈ 895ms
DuckDB-WASM 比纯 JS 快了 10 倍，加上省掉的网络开销，实际体验比走服务端还快。
4.4 数据格式的选择很关键
这里有个容易忽略的点：文件格式对性能影响巨大。同样 30 万行数据：
- 用 CSV 格式加载到 DuckDB-WASM：解析耗时 1200ms
- 用 Parquet 格式加载：解析耗时 150ms
差了 8 倍。原因是 Parquet 本身就是列式存储格式，DuckDB 读 Parquet 几乎是零解析成本。所以我们的方案是：Excel 上传后，前端先用 SheetJS 解析成 JSON，再用 parquet-wasm（又一个 WASM 工具）转成 Parquet 格式喂给 DuckDB。虽然转换本身要几百毫秒，但后续每次查询都能享受 Parquet 的性能红利，整体算下来非常划算。
七、决策速查表
| 判断维度 | 适合 WASM | 适合服务端 |
|---|---|---|
| 数据大小 | < 1GB | > 1GB |
| 单次计算耗时 | < 30 秒 | > 30 秒 |
| 是否涉及数据库 | 不涉及 | 涉及 |
| 隐私合规要求 | 数据不能离开客户端 | 服务端有合规方案 |
| 调用频次 | 用户频繁交互调整 | 一次性批处理 |
| 网络环境 | 弱网/离线场景 | 稳定网络 |
| 计算类型 | CPU 密集 | GPU 密集/需要特殊硬件 |
我的判断流程是：先看数据能不能出浏览器（合规），再看计算量用户端能不能扛住（性能），最后看开发维护成本是否可接受（ROI）。三个条件都满足，就值得用 WASM。
