Go 1.21+ 是硬门槛，低于该版本不支持 GOOS=wasm GOARCH=wasm 直出标准 .wasm 文件，旧版仅支持需 wasm_exec.js 的 GOOS=js 方案，二者不兼容。
Go 1.21+ 是硬门槛，低于它就别试 wasm 编译——GOOS=wasm GOARCH=wasm 组合在旧版里会静默失败或报错，不是配置问题，是根本没实现。
确认 Go 版本是否支持原生 WASM 编译
执行 go version，输出必须含 go1.21 或更高。低于这个版本，GOOS=wasm GOARCH=wasm go build 不会生成可用的 .wasm 文件，也不会明确提示“不支持”，而是编译出无法加载的空模块或直接报 build constraints excluded all Go files 类错误。
常见误判点：有人看到 Go 1.19 能跑 GOOS=js 就以为能用，但那是旧方案（依赖 wasm_exec.js + JS 胶水层），而 GOOS=wasm 是纯字节码方案，两者不兼容、不可混用。
- Go 1.21+ 才真正支持
GOOS=wasm GOARCH=wasm直出 .wasm 文件 - Go 1.20 及更早版本，只能用
GOOS=js GOARCH=wasm，且必须配对$GOROOT/misc/wasm/wasm_exec.js - 升级 Go 后记得清掉旧的
GOOS=js编译缓存，避免go build复用错误目标架构
编译命令与产物差异：GOOS=wasm vs GOOS=js
GOOS=wasm GOARCH=wasm 产出的是标准 WebAssembly 字节码（.wasm），无 JS 胶水，需手动加载；GOOS=js GOARCH=wasm 产出的是兼容旧浏览器的混合方案，依赖 wasm_exec.js 提供 syscall/js 运行时桥接。
立即学习“go语言免费学习笔记（深入）”；
如果你的目标是现代浏览器（Chrome 110+ / Firefox 115+ / Safari 17+），优先选 GOOS=wasm：体积更小、启动更快、GC 行为更可控；若需支持 Safari 16 或更老版本，才退回到 GOOS=js。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
GOOS=wasm GOARCH=wasm go build -o main.wasm main.go→ 输出纯main.wasm -
GOOS=js GOARCH=wasm go build -o main.wasm main.go→ 输出仍叫main.wasm，但实际是 JS 包装过的变体，必须搭配wasm_exec.js使用 - 两种模式都禁用
net/http、os.Exit、time.Sleep等系统调用，否则运行时报invalid memory access或直接崩溃
浏览器加载失败的三个高频原因
编译成功 ≠ 能跑起来。最常卡在加载环节，错误信息通常是模糊的 CompileError: WebAssembly.instantiateStreaming() failed 或空白控制台无输出。
根本原因只有三个，按出现频率排序：
- 用
file://协议双击打开 HTML —— 浏览器禁止本地加载 WASM，必须走 HTTP 服务（python3 -m http.server或go run net/http起个最小服务） - JS 加载逻辑没 await
WebAssembly.instantiateStreaming()的 Promise，或没处理 reject，导致 wasm 实例未初始化就调用 Go 导出函数 - Go 代码里没写
js.Wait()（GOOS=wasm模式）或select{}（GOOS=js模式），main 函数执行完立刻退出，回调注册失效
性能与调试注意事项
WASM 不是万能加速器。Go 编译出的 WASM 在浏览器里仍受沙箱限制：没有线程（除非显式启用 WebAssembly Threads 且用户浏览器支持）、GC 停顿不可控、内存分配开销比原生高 2–3 倍。
实测中，纯计算密集型任务（如 SHA256、矩阵乘法）能达 JS 的 2–4 倍速度；但涉及频繁 DOM 操作或小对象高频分配时，反而比优化后的 JS 慢。
- 避免在 Go 侧做
document.getElementById链式调用，应由 JS 层传入已查好的 element 引用 - 日志不要只靠
fmt.Println，它输出到 console 但不可捕获；需重定向：log.SetOutput(js.Global().Get("console").Call("log")) - 调试时开启 Chrome DevTools 的 “WebAssembly Debugging” 实验性功能，并在 Go 代码里加
runtime.Breakpoint()插桩
真正难的不是编译出 .wasm，而是让 Go runtime 在浏览器沙箱里稳住不崩、不漏内存、不卡主线程——这些细节不写进 main 函数第一行，后面全白搭。
