AhaConvert

几个月前，我需要给一个 Web 应用添加文件转换功能——没什么复杂的，就是让用户拖入一个文件，然后得到另一种格式。起初我的想法是“调用 API 就搞定”。但把用户文件发送到服务器意味着存储成本、隐私问题，以及流量高峰时的排队。所以我开始研究如何完全在客户端使用 WebAssembly 完成转换。以下是我学到的经验，包括那些入门教程里不会提到的部分。

为什么要在这种场景中使用 WASM

大多数格式转换逻辑（编解码器、容器解析、压缩）都是用 C/C++ 或 Rust 编写的，而且生态已经非常成熟。将它们编译为 WASM 意味着你可以在浏览器标签页内获得接近原生的解码/编码速度，且无需任何服务器往返。对于许多格式来说，这速度已经足以满足实时使用。
最常见的构建块是 FFmpeg 的 WASM 构建（最流行的是 ffmpeg.wasm）。它提供了与原生 FFmpeg 相同的编解码器，只是在 Web Worker 中运行。

棘手的地方

内存是第一个障碍
WASM 线性内存有上限，大型视频文件很容易超出。你要么需要对输入进行分块处理、流式传输，要么接受非常大的文件在浏览器中无法工作。这没有干净的解决办法——这是一个真实的上限，而非简单的配置调整。
多线程支持不完整
多线程 WASM 构建所需的 SharedArrayBuffer 需要服务器返回特定的 COOP/COEP 响应头。如果缺少这些头，应用会静默回退到单线程模式——速度更慢，而且不会给出错误提示。
打包体积比想象中更重要
一个 WASM FFmpeg 构建可能达到 20-30MB。对于专用转换工具来说还算可以，但如果转换只是应用的附加功能，这会对首次加载时间造成明显影响。
格式覆盖并不全面
视频和音频支持较好。某些专有图像格式（某些相机 RAW 变体、一些旧文档格式）要么不受开源 WASM 库支持，要么需要更重的自定义构建才能正确处理。

真正发挥作用的场景

如果用户主要转换常见格式（MP3/WAV/AAC 音频、标准图像类型和常见视频编解码器），且文件大小适中，那么浏览器端 WASM 转换是一种可靠且注重隐私的方案——文件永远不会离开设备。这其实也是同类工具背后的权衡。
如果你自己构建这个功能，请为上述内存和响应头问题预留真实时间——这些问题只有在用真实文件（而非 2MB 示例）测试时才会暴露。