能安全编译进 wasm 的 go 代码必须不调用 syscall、不依赖 cgo、不使用 os/exec、net、http.server 等宿主强绑定模块,仅限纯逻辑层,如数据校验、加解密(非最优)、状态机、dto 序列化等。

Go 编译到 Wasm 后无法直接复用标准库中的 net/http、database/sql 等后端专属包,所谓“代码共享”实际仅限于纯逻辑层(无 OS/网络/文件依赖),且必须主动隔离平台相关代码。
哪些 Go 代码能安全编译进 Wasm?
能跑在 Wasm 上的 Go 代码必须满足:不调用 syscall、不依赖 cgo、不使用 os/exec、net、http.Server 等宿主环境强绑定模块。典型可用场景包括:
- 数据校验逻辑(如
validateEmail()、parseISO8601()) - 加解密算法(AES、HMAC,但注意 Web Crypto API 在浏览器中更高效)
- 状态机、规则引擎、表达式求值(如基于
go-interpreter的轻量 DSL) - DTO 结构体 +
json.Marshal/Unmarshal(需启用GOOS=js GOARCH=wasm构建)
一旦出现 panic: not implemented 或 undefined: syscall,说明代码越界了——这不是配置问题,是架构约束。
如何组织跨平台共享模块?
推荐用 Go 的构建标签(build tag)做物理隔离,而非运行时判断:
// shared/math.go
//go:build !wasm || wasm_shared
// +build !wasm wasm_shared
package shared
func RoundToTwo(x float64) float64 {
return float64(int(x*100+0.5)) / 100
}
然后在 Wasm 侧构建时显式启用标签:
Go 配置库,使用 spf13/viper — 分层优先级(flag > env >file > KV > default),提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
GOOS=js GOARCH=wasm go build -tags wasm_shared -o main.wasm ./cmd/wasm
关键点:
- 避免用
// +build wasm单独标记 Wasm 专用代码——它会把非 Wasm 构建完全排除 - 共享逻辑应放在独立
shared/模块,禁止在其中 importnet/http等包 - 如果共享代码需调用 JS 函数(如生成 UUID),用
syscall/js,但该调用不可被服务端复用
Wasm 中调用共享函数的实际链路
Go 编译出的 Wasm 不是开箱即用的 JS 模块,需手动桥接:
// main.go(Wasm 入口)
func main() {
c := make(chan struct{}, 0)
js.Global().Set("validateInput", js.FuncOf(func(this js.Value, args []js.Value) interface{} {
input := args[0].String()
return shared.Validate(input) // ← 调用共享包
}))
<p>前端 JS 调用时:</p>
<pre class="brush:php;toolbar:false;">const go = new Go();
WebAssembly.instantiateStreaming(fetch("main.wasm"), go.importObject).then((result) => {
go.run(result.instance);
console.log(validateInput("test@example.com")); // true
});
注意:
-
shared.Validate必须是导出函数(首字母大写),且参数/返回值只能是基础类型或js.Value - 不能直接传入 Go 的 struct 指针给 JS;需序列化为 JSON 字符串再解析
- 每次调用都是同步阻塞的,高频调用需考虑批量接口或 Worker 分离
真正的难点不在编译或调用,而在于边界划分——一旦共享模块开始依赖时间、随机数、加密上下文等看似“通用”的能力,就立刻面临浏览器 API(crypto.getRandomValues)和服务端 Go 标准库(crypto/rand)的语义分裂。这时候与其强行复用,不如用接口抽象 + 两套实现更可控。










