能安全编译进 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 侧构建时显式启用标签：
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) // ← 调用共享包
}))
<-c
}
前端 JS 调用时：
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）的语义分裂。这时候与其强行复用，不如用接口抽象 + 两套实现更可控。
