Golang中WebAssembly的设计决策解析

Golang中WebAssembly的设计决策解析 根据我使用其他语言（C++、Rust）的经验，WebAssembly 模块应该像库一样使用，它是一个导出了一系列函数的二进制文件。

然而，Go 将 WebAssembly 视为一个可执行文件。在运行时，函数可以注册到全局 JS 对象中。只要主方法在运行，这些函数就是可调用的。每个人，包括我自己，都使用等待通道模式来让主方法永远运行。但是……为什么呢？

我仔细查阅了关于 WebAssembly 支持的那个长达 500 多条评论的初始问题（https://github.com/golang/go/issues/18892）。读起来非常有趣，neelance 挺身而出进行尝试，然后让每个人都参与了他的旅程！我向你致敬，neelance！

但我找不到任何解释为什么 Go 不遵循 WebAssembly 的导出功能。 我并不是说这不好，实际上开发体验相当不错，Go 和 JS 之间的互操作性很棒。 我只是想知道做出这个决定的原因是什么。 有人知道吗？也许是因为 GC？


更多关于Golang中WebAssembly的设计决策解析的实战教程也可以访问 https://www.itying.com/category-94-b0.html

1 回复

更多关于Golang中WebAssembly的设计决策解析的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


Go 选择将 WebAssembly 模块作为可执行文件而非纯库的设计决策，主要源于 Go 的运行时模型和垃圾回收机制的需求。Go 程序需要一个初始化的运行时环境，包括 goroutine 调度器、内存管理器和垃圾回收器，这些必须在 WASM 模块启动时建立。如果仅导出独立函数，每个函数调用都需要独立的运行时状态，这会带来显著的性能开销和复杂性。

以下是一个示例，展示了 Go 在 WASM 中注册函数供 JavaScript 调用的典型模式：

// main.go
package main

import (
    "syscall/js"
)

func main() {
    // 注册函数到全局 JavaScript 对象
    js.Global().Set("goAdd", js.FuncOf(func(this js.Value, args []js.Value) interface{} {
        if len(args) != 2 {
            return "Invalid number of arguments"
        }
        a := args[0].Int()
        b := args[1].Int()
        return a + b
    }))

    // 保持主 goroutine 运行，以便函数保持可调用状态
    <-make(chan bool)
}

编译命令：

GOOS=js GOARCH=wasm go build -o main.wasm main.go

在 JavaScript 中调用：

// 加载并实例化 WASM 模块后
console.log(goAdd(5, 3)); // 输出: 8

这种设计确保了 Go 的运行时在整个 WASM 模块生命周期内保持活动状态，避免了每次函数调用时重复初始化和清理的开销。对于需要导出多个函数的情况，Go 通过 js.FuncOf 将 Go 函数包装为 JavaScript 可调用函数，并挂载到全局对象上。虽然这不同于传统的库模式，但它与 Go 的并发模型和垃圾回收机制紧密结合，提供了稳定的执行环境。

回到顶部