根本原因是go版本过低或未启用wasm支持；需go 1.11+并设goos=js goarch=wasm，用go build生成.wasm，响应头须含application/wasm，禁用cgo，js调go需通过syscall/js序列化数据，避免阻塞操作。
Go 编译 WASM 时为什么浏览器报错 instantiateStreaming failed: CompileError
根本原因通常是 Go 版本太低或未启用 WASM 支持。Go 1.11+ 才原生支持 WASM，但默认不开启；1.21+ 起仍需手动指定 GOOS=js GOARCH=wasm，且不能用 go run 直接运行。
- 必须用
go build -o main.wasm main.go，且提前设置环境变量：GOOS=js GOARCH=wasm - Go 1.22 开始，
runtime/debug.ReadBuildInfo()在 WASM 中不可用，会静默失败——别在初始化逻辑里调它 - WASM 模块加载必须走
WebAssembly.instantiateStreaming()，且响应头需含content-type: application/wasm；用file://协议直接打开 HTML 会因 CORS 失败
怎么从 Go 向 JavaScript 传参并拿到返回值
Go 的 syscall/js 包是唯一官方通道，但它不支持 Go 原生类型直传（比如 struct、map），所有数据必须序列化为 JSON 或拆成基础类型。
- 导出函数必须注册到
js.Global().Set()，且签名只能是func(js.Value, []js.Value) interface{} - JS 调 Go 函数时，参数是
js.Value，需用.String()、.Int()等显式转换；Go 返回值会被自动转成 JS 类型，但nil变成undefined，不是null - 别在 Go 导出函数里启动 goroutine 并异步返回——JS 不等它，会立刻收到
undefined
func add(_ js.Value, args []js.Value) interface{} {
a := args[0].Float()
b := args[1].Float()
return a + b // 自动转成 JS number
}
js.Global().Set("add", js.FuncOf(add))
为什么 Go WASM 体积比 Rust 大 5–10 倍
Go 运行时（GC、goroutine 调度、反射）全被打包进 .wasm，而 Rust 默认无运行时。这不是配置问题，是语言模型决定的硬开销。
-
go build -ldflags="-s -w"可去掉调试信息，减小约 15%，但无法消除运行时主体 - 禁用 CGO（确保
CGO_ENABLED=0）是必须的，否则构建直接失败 - 若只需数学计算或算法逻辑，优先考虑用
tinygo替代标准 Go：它支持子集语法，生成体积接近 Rust，但不兼容net/http、encoding/json等包
JS 调 Go 函数后页面卡死，怎么排查
90% 是 Go 代码触发了同步阻塞，比如 time.Sleep、未加超时的 http.Get，或死循环——WASM 是单线程，没有“后台线程”概念，任何阻塞都会锁死整个 JS 主线程。
- 所有 I/O 操作必须用
js.Promise封装，把控制权交还 JS；Go 侧不能等 Promise resolve，只能靠回调 -
runtime.GC()在 WASM 中是空操作，别指望它缓解内存压力 - 用浏览器 DevTools 的 “Performance” 面板录制，看主线程是否长时间处于 “Scripting” 状态，定位卡点函数
js/wasm 构建下实际有效，而不是仅“能编译”。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
