Go 1.21+原生支持WASM，需用GOOS=wasm GOARCH=wasm编译纯.wasm文件，依赖js.Wait()阻塞、syscall/js交互DOM，禁用net/http，须HTTP服务托管且注意性能与GC限制。
Go 1.21+ 直接支持 WASM，无需额外工具链
Go 官方从 go1.21 开始原生支持 WebAssembly 编译，不需要装 emsdk、binaryen 或手动 patch GOOS=js。你用的 Go 版本如果低于 1.21，GOOS=wasm GOARCH=wasm go build 会报错或静默失败——这是最常卡住的第一步。
确认方式很简单：go version 输出必须含 go1.21 或更高。低于这个版本，请升级 Go，别折腾旧版兼容补丁。
-
GOOS=wasm GOARCH=wasm是唯一正确组合，GOOS=js已废弃，继续用会生成过时的main.wasm+wasm_exec.js混合方案 - 编译产物是纯 WASM 字节码（
.wasm），不带 JS 胶水代码，得自己写加载逻辑或用syscall/js的替代方案 - 不支持
net/http服务端模型——WASM 运行在浏览器沙箱里，没有监听端口能力
用 syscall/js 写交互逻辑，但注意它已被标记为 deprecated
如果你要让 Go 代码响应按钮点击、读取 DOM、触发 alert，目前仍得靠 syscall/js。但它在 Go 1.22 中已标为 deprecated，官方推荐迁移到 golang.org/x/webassembly（尚未发布稳定版），所以短期还得用，但得清楚边界。
常见错误是直接在 main() 里写业务逻辑，导致程序立即退出。WASM 模块启动后会执行 main()，然后结束——除非你显式阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 必须调用
js.Wait()阻塞主线程，否则 Go runtime 瞬间退出，回调注册失效 - 所有 DOM 操作必须通过
js.Global().Get("document")等方式桥接，不能用标准库的os或net -
fmt.Println默认输出到浏览器 console，不是终端；想捕获日志需重定向log.SetOutput到js.Global().Get("console").Call("log")
编译出的 wasm 文件不能直接双击打开
浏览器出于安全限制，不允许本地 file:// 协议加载 WASM 模块，直接双击 HTML 会看到 Failed to instantiate WebAssembly module: CompileError: WebAssembly.instantiateStreaming() failed 或更模糊的网络错误。
这不是代码问题，是运行环境问题。你必须用一个最小 HTTP 服务提供文件。
- 最简方案：
go run -m ./server.go启一个http.FileServer，根目录放你的index.html和main.wasm - 别用
python -m http.server：Python 3.9+ 默认不返回application/wasmMIME 类型，Chrome 会拒绝加载；需加 header 或换工具 - 确保
index.html中WebAssembly.instantiateStreaming(fetch("main.wasm"))的路径正确，相对路径易错，建议用绝对路径如/main.wasm
性能敏感操作别在 WASM 里做，尤其是 goroutine 大量创建
Go 的 goroutine 在 WASM 下是模拟的协作式调度，不是 OS 线程。大量并发（比如开几百个 go func()）会导致严重卡顿甚至栈溢出，因为 WASM 内存是线性内存，且无原生线程支持（GOEXPERIMENT=wasmthreads 仍实验中）。
典型误用：把原本服务器上跑的批量处理逻辑照搬进 WASM，结果页面冻结。
- IO 密集型任务（如解析大 JSON、图像像素遍历）可以，但要用
js.CopyBytesToGo避免频繁跨边界拷贝 - CPU 密集型计算建议分片 +
setTimeout让出主线程，否则浏览器判定“页面无响应”并弹框 - GC 压力比 native 高，避免在热循环中分配新 slice 或 struct；复用
sync.Pool效果有限，优先栈分配
WASM 不是“把 Go 服务端代码扔进浏览器就能跑”，它是另一套执行约束模型。最常被忽略的是：你写的不是“程序”，而是一个被浏览器 runtime 管控的插件模块。
