在前端的世界里，我們習慣把 HTML、CSS、JavaScript 看作“三劍客”。它們各司其職：HTML 負責結構，CSS 負責樣式，JavaScript 則賦予頁面交互和邏輯。但隨著 WebAssembly（簡稱 Wasm）的出現，一門新的“第四語言”正在走進開發者的視野。

WebAssembly 不是用來取代 JavaScript 的，它更像是補充和增強。過去，瀏覽器端要運行 C/C++、Rust、Go 這樣的語言并不現實，而 Wasm 給了它們一個共同的目標：編譯為高效、緊湊、跨平臺的二進制格式，然后直接在瀏覽器里跑。

WebAssembly 是什么？

簡單來說，WebAssembly 是一種運行在瀏覽器中的字節碼標準。它設計得接近底層機器碼，因此體積小、加載快、執行效率高。對于開發者而言，它最大的意義在于：

?多語言支持：不止 JS，C、C++、Rust、Go、Kotlin、Dart、Java 等都能編譯到 Wasm。

?高性能：接近原生的執行速度，特別適合性能敏感場景。

?跨平臺：一次編譯，到處運行，既能跑在瀏覽器里，也能在獨立運行時（Wasmtime、Wasmer 等）里執行。

在前端能用來做什么？

過去幾年，Wasm 已經在不少真實場景落地：

?圖像和視頻處理：例如 Web 上的 PS、視頻編輯器，可以用 C++ 庫直接編譯到 Wasm，避免性能瓶頸。

?游戲和 3D 應用：Unity、Unreal 等引擎都能輸出 Wasm 版本，讓大型游戲直接跑在瀏覽器。

?機器學習推理：在瀏覽器里跑 ONNX 或 TensorFlow.js 模型時，Wasm 能顯著提升推理速度。

?數據庫和虛擬機：SQLite、Postgres 子集、甚至 Python 解釋器，都有 Wasm 版本，可以嵌入網頁。

換句話說，凡是 JS 難以高效處理的大計算量任務，都可能交給 Wasm。

WebAssembly 3.0

9 月 17 日，WebAssembly 3.0 正式發布，帶來了一系列“質變”的改進。

圖片

主要包括：

?64 位地址空間： 之前 Wasm 的內存尋址基于 32 位，最多只能用到 4GB 內存。對于圖像處理、模型推理這些場景來說，這遠遠不夠。3.0 引入了 64 位地址模式，理論上能支持到 16EB。雖然瀏覽器端依舊有限制（通常 16GB），但已經能覆蓋大部分高性能計算的需求。

?多內存支持：以前一個 Wasm 模塊只有一塊內存，所有數據都混在一起。現在可以定義多塊獨立內存區，不同庫、不同邏輯模塊各用各的，既避免沖突，也更易于管理。

?垃圾回收與類型化引用：這是 3.0 最受期待的特性之一。Java、Kotlin、OCaml 等語言終于能“順理成章”地編譯到 Wasm，不必再額外模擬對象系統。對前端開發者來說，這意味著未來可能直接在瀏覽器中運行更多高級語言應用。

?異常處理與尾調用：異常機制讓 Wasm 內部能像 JS 一樣捕獲和拋出錯誤，不需要頻繁切換上下文。尾調用優化則讓函數式語言的遞歸更加高效，不再輕易因為棧溢出而崩潰。

?SIMD 和確定性配置：Wasm 一直在補齊性能指令集。3.0 放寬了 SIMD 的部分語義，以獲得更好的執行效率；同時也引入了確定性配置，確保在區塊鏈、可重放測試等場景里，結果可以跨平臺保持一致。

?更緊密的 JS 字符串交互：WebAssembly 和 JavaScript 的邊界又被進一步打薄。3.0 中，字符串的傳遞和處理效率大幅提升，減少了拷貝和內存開銷，這對大量文本處理的應用（比如編譯器、編輯器）非常關鍵。

寫在最后

從 2017 年進入瀏覽器，到如今的 3.0，WebAssembly 已經走過了八年。它不再只是“給 JS 打下手的二進制模塊”，而是越來越像前端的第四門語言。

對開發者來說，這帶來了幾個直接影響：

?性能敏感的模塊，可以更安心地交給 Wasm 去跑；

?未來會有更多語言，以接近原生的方式登陸瀏覽器；

?同時我們也要學會新的調試、測試與部署方法，理解 Wasm 的邊界。

Wasm 3.0 不會一夜之間改變前端生態，但它確實讓“瀏覽器也能跑近似原生應用”這句話，更加真實。接下來幾年，這門“第四語言”很可能會在前端格局里占據越來越重要的位置。