在 Web 性能优化的语境下，Rust 搭配 WebAssembly 通常被视为通往极致性能的银弹。然而，最近一个来自 OpenUI 团队的真实案例却给出了截然相反的答案：将 Rust WASM 解析器重写为纯 TypeScript 实现后，性能提升了约 3 倍。这一逆向结果并非因为 TypeScript 本身比 Rust 更快，而是揭示了跨语言边界调用中容易被忽视的结构性开销。本文将深入拆解这一案例背后的技术细节，提炼出可复用的工程决策框架。
场景复现：流式解析器的架构选择
该团队构建了一个流式解析器，功能是将大语言模型的输出逐步转换为 React 组件。由于需要处理每一个 token 级别的数据块，解析器在每次模型输出新内容时都会被触发。最初的技术选型是 Rust 编译为 WebAssembly，理由很直观：Rust 拥有精细的内存控制和高性能的字符串处理能力，配合 WASM 可以在浏览器端实现接近原生的计算速度。
然而，实测性能却远未达到预期。profiling 结果显示，解析逻辑本身并非瓶颈所在 —— 真正消耗时间的，是每一次调用中 Rust 与 JavaScript 之间的边界跨越。具体而言，每个数据块的处理需要经历以下四个步骤：首先将 JavaScript 字符串拷贝进入 WASM 内存空间；然后在 Rust 端将数据序列化为 JSON 格式；接着通过 WASM 接口将数据传回 JavaScript 端；最后由 V8 引擎完成反序列化。这种高频次、小数据量的跨边界操作，导致固定开销远远超过了实际计算成本。
根因剖析：边界开销为何如此昂贵
要理解这一现象，需要从 V8 的 JIT 编译机制和内存布局两个维度来审视。在 V8 的执行模型中，JavaScript 代码在运行过程中会被即时编译为机器码，热点代码会进入 TurboFan 优化编译器实现内联和向量化。然而，当调用跨越 WASM 边界时，V8 必须退出优化编译路径，切换到一种更为保守的执行模式。这是因为 WASM 模块拥有独立的内存空间和类型系统，V8 无法在其间进行跨边界的类型推导和代码内联。
每一次 JS 调用 WASM 函数，都涉及参数 marshaling—— 将 JS 对象转换为 WASM 线性内存中的二进制表示。返回数据同样需要经历反向转换。对于小数据量的高频调用，这个转换过程的固定开销会呈线性累积，最终成为性能的主导因素。根据团队测试，当使用 serde-wasm-bindgen 直接返回 JavaScript 对象时，性能反而比简单的字符串加 JSON.parse 方案下降了约 30%。这说明即使尝试绕过 JSON 序列化，复杂的对象绑定层同样会引入可观的边际成本。
从内存布局角度看，Rust 端的数据结构和 JavaScript 端的 V8 对象在内存表示上存在根本差异。Rust 的 String 类型采用连续的堆分配字节数组，而 JavaScript 的字符串则是经过复杂优化的内部结构，包含长度缓存、哈希码和可配置的编码方式。两者之间的每一次拷贝，都涉及内存分配、GC 注册和潜在的类型检查。这些操作在单个大块数据的场景下可以被摊销，但在细粒度的流式处理中会成为瓶颈。
TypeScript 方案的优化本质
将解析器完全用 TypeScript 重写后，性能提升的根因在于消除了跨语言边界的所有开销。数据不再需要离开 V8 的管控范围，解析逻辑可以在 TurboFan 的优化路径上全速运行。V8 对 JSON.parse 有着极其深度的手工优化，底层使用了快速路径和非竞争解码技术，在处理中等大小的 JSON 字符串时可以达到接近 C 语言的解析速度。更重要的是，数据保持在 JavaScript 的对象图内，无需经历序列化 - 反序列化的往返过程。
这并不意味着 Rust 或 WASM 本身性能不佳。恰恰相反，在计算密集型任务中 —— 如图像处理、密码学运算、大型文件的批量解析 ——Rust WASM 仍然具备显著优势。关键在于，当计算量无法摊销跨边界开销时，优势就会转化为劣势。OpenUI 团队的案例本质上是一个典型的「高频率、小粒度」工作负载，解析每个 token 的计算量可能只有几百个 CPU 周期，而边界跨越的成本可能达到数千个周期。
工程决策框架：何时选择哪种方案
基于上述分析，可以提炼出几个可操作的判断准则。首先，评估单位工作负载的计算密度：如果每个调用周期的纯计算时间低于约 1 微秒，且调用频率超过每秒 1000 次，则应优先考虑纯 JS 方案。其次，测量边界开销的占比：在目标环境中进行基准测试，对比单次调用的总耗时与纯计算耗时，边界开销占比超过 30% 时即应警惕。
对于坚持使用 Rust WASM 的场景，也有几条优化路径可以显著降低边界成本。其一，将多次小调用合并为单次大调用，通过积累一定数量的数据块后再一次性处理，将边界次数从 N 降至 1。其二，使用共享内存机制传递数据，利用 WebAssembly.Memory 的 buffer 属性直接在 JS 和 WASM 之间共享字节数组，避免拷贝。其三，避免在边界上传递复杂对象，优先使用字符串或 Uint8Array 作为接口，以 V8 原生解析能力替代手动序列化。
最后一条建议与监控策略相关。在生产环境中，建议对 WASM 模块的调用耗时进行细粒度追踪，区分「纯计算时间」和「总调用时间」。当两者差距持续超过阈值时，就是重新评估架构的信号。这一原则不仅适用于解析器场景，也是所有涉及 WASM 与 JS 混合开发项目的通用优化方向。
资料来源：本文技术细节主要基于 OpenUI 团队在 Reddit Rust 社区的技术分享，原始博客发布于 openui.com/blog/rust-wasm-parser。