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 基本一致。关键代码长这样：

javascript 复制代码

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 的安全限制。

makefile 复制代码

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 模块。封装后的调用接口大概是这样：

javascript 复制代码

// 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。

javascript 复制代码

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 列）：

scss 复制代码

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。