2026 WebAssembly 執行器誰變快了
7 個 WebAssembly 執行器在 2026 年的 libsodium 基準顯示明顯分化，wide_arithmetic 對加密效能的影響最大。
這篇比較 7 個 WebAssembly 執行器在 2026 年的 libsodium 加密基準，幫你判斷哪個最適合追求速度。
看完這份清單，你可以直接判斷：你的 Wasm 工作負載該優先測哪個 runtime，以及是否值得為 wide_arithmetic 重新跑一次基準。
| 項目 | 2024 | 2025 | 2026 |
|---|---|---|---|
| Wasmtime | 2.67x native | 2.54x native | 2.41x native |
| Node | 8.60x native | 7.95x native | 7.95x native |
| WAMR | n/a | 1.59x native | 1.57x native |
| wasm2c | 2.83x native | 2.66x native | 2.49x native |
| WasmEdge | 2.20x native | 2.02x native | 1.74x native |
| Wasmer | 2.30x native | 2.37x native | 2.08x native |
| Bun | 12.45x native | 26.03x native | 8.77x native |
1. Wasmtime：穩定變快，還吃得到新指令
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Wasmtime 是這組資料裡最像「穩定進步」的例子。基礎版本從 2024 的 2.67x native，走到 2026 的 2.41x native，速度提升不誇張，但趨勢很清楚。
真正的轉折在 wide_arithmetic。2026 版一開這個特性，Wasmtime 直接降到 1.46x native，對 libsodium 這類算術密集工作是很實際的收益。
- 2026 基準：2.41x native
- wide_arithmetic：1.46x native
- 適合：能利用新版 Wasm 指令的加密程式
2. Wasmer：開啟 wide_arithmetic 後最有爆發力
Wasmer 的基準歷史不算一路順風，但 2026 版很關鍵，因為它終於明顯吃到 wide_arithmetic 的紅利。純基礎版是 2.08x native，屬於穩健但不特別突出。
一旦啟用 wide_arithmetic，Wasmer 下降到 1.33x native，成為這組測試裡最快的完整現代結果。對 CPU-heavy 的 crypto 工作，這種差距足以改變部署選擇。
- 2026 基準：2.08x native
- wide_arithmetic：1.33x native
- 重點：功能支援比單看基準更重要
3. WAMR：小而快，但不吃新算術指令
WAMR 的故事比較安靜。在 AOT 模式下，2025 與 2026 版都維持在 1.6x native 左右，對可攜式 WebAssembly 來說已經很強。
限制也很明確。WAMR 能跑基礎版和 SIMD-lime 變體，但 wide_arithmetic 會因為不支援的 opcode 直接失敗。如果你的程式需要最新算術指令，它不是目前最穩的選擇。
- 2025 基準：1.59x native
- 2026 基準：1.57x native
- 限制：這次測試不支援 wide_arithmetic
4. WasmEdge：模式選對，成績差很多
WasmEdge 的進步有感，但這份測試也提醒一件事：執行模式會嚴重影響結果。2026 年一開始誤用 interpreter mode，成績看起來很差，改成 AOT 後才回到合理水準。
在 AOT 下，2026 基準落在 1.74x native，比前幾年更好，足以把它放進「速度不錯」的名單。前提是你得自己控制執行模式。
- 2024 基準：2.20x native
- 2025 基準：2.02x native
- 2026 AOT 基準：1.74x native
5. wasm2c：走編譯鏈，換來穩定可控
wasm2c 是比較務實的路線：先把 Wasm 轉成 C，再交給主機編譯器處理。它不追 runtime 花招，但在這組測試裡一直維持不錯的表現。
2026 基準是 2.49x native，雖然不是最快，但改善幅度穩定。若你的建置流程本來就偏向原生編譯，這條路很順。
wasm2c -> C -> zig cc -O3 -march=native6. Node：慢慢進步，但還離最快很遠
Node 的改善幅度不大，但至少不是停滯。基準從 2024 的 8.60x native，走到 2025 的 7.95x native，2026 也大致維持在這個區間。
它還暴露了一個實務問題：某些 libsodium 測試要先設好明確的最大線性記憶體，否則會失敗。也就是說，能不能跑完，有時比跑多快更重要。
- 2024 基準：8.60x native
- 2026 基準：約 7.95x native
- 注意：要設 explicit linear memory
7. Bun：一年內變化最大，但波動也最大
Bun 是這份資料裡年際變化最戲劇化的項目。2024 和 2025 的結果都落後不少，但 2026 版把差距大幅縮小，基準成績來到 8.77x native。
這仍然比 Node 慢，但改善幅度夠大，代表它不再是這類工作負載的明顯外圍選項。如果團隊已經在用 Bun，2026 數字值得重新驗證自己的程式。
- 2024 基準：12.45x native
- 2025 基準：26.03x native
- 2026 基準：8.77x native
哪種適合你：先看功能，再看名次
如果你要的是 2026 年這組 crypto Wasm 測試裡的最快結果，先測 Wasmer 和 Wasmtime，再確認你的模組能不能用 wide_arithmetic。這兩個 runtime 吃到新指令後，排名會明顯翻動。
如果你重視可攜性、AOT、或既有建置流程，WAMR、WasmEdge 和 wasm2c 更值得先試。Node 和 Bun 都在進步，但就這個工作負載來看，還是落後專用 runtime。最後的結論很簡單：跑你自己的模組，因為執行模式和功能支援，常常比名字更重要。