Go 1.21+ 编译 WASM 需指定 GOOS=js GOARCH=wasm，生成的 main.wasm 须配合 wasm_exec.js 胶水代码手动加载并调用 run() 启动，且需 defer js.Sleep(1) 防止协程退出卡死。
Go 1.21+ 编译 WASM 需要 GOOS=js GOARCH=wasm
Go 官方从 1.11 开始支持 WASM，但真正稳定可用是从 1.21 起。旧版本（如 1.20 及之前）编译出的 main.wasm 在现代浏览器里大概率报 RuntimeError: unreachable 或直接空白——不是你代码错，是 Go 运行时没对齐浏览器 WASI 环境。
正确命令只有一行：
GOOS=js GOARCH=wasm go build -o main.wasm main.go
-
GOOS=js是关键，它让 Go 启用 JS 目标平台专用的运行时（含syscall/js绑定），不是“跨平台编译”的泛称 -
GOARCH=wasm必须和GOOS=js配对，单独设GOARCH=wasm会静默忽略 - 输出是纯 WASM 字节码，不带 HTML/JS 胶水代码，不能直接双击打开
必须手写胶水 JS 才能跑起来，syscall/js 不是自动注入的
Go 编译出的 main.wasm 本质是个“无主模块”：它依赖 syscall/js 提供的宿主接口（比如 js.Global()、js.FuncOf()），但这些函数不在 WASM 里，得靠外部 JS 加载并注入。
官方提供的 $(go env GOROOT)/misc/wasm/wasm_exec.js 就是这个胶水文件，但它只是搬运工，不替你调用 main()。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式用
WebAssembly.instantiateStreaming()加载main.wasm，再手动调用run()启动 Go 主循环 - 忘记加
defer js.Sleep(1)或select{}会导致 Go 协程退出后页面卡死——WASM 没有后台线程，主 goroutine 结束 = 整个实例销毁 - 常见错误现象：
Uncaught (in promise) TypeError: Failed to execute 'arrayBuffer' on 'Response': body stream already read，多因重复调用instantiateStreaming或未处理 fetch 流
net/http 和 os/exec 在 WASM 下完全不可用
WASM 沙箱没有文件系统、没有网络栈、没有进程概念。所有依赖操作系统能力的标准库都会编译失败或 panic。
比如这段代码：
http.Get("https://api.example.com") // 编译通过，但运行时 panic: "not implemented"
或者：
exec.Command("ls") // 编译失败：undefined: exec.Command
-
net/http的 client 端被阉割，仅保留 server 端（但 server 无法绑定端口，实际也废） - 替代方案只能是
fetch+syscall/js调用，例如：js.Global().Get("fetch").Invoke(url) -
time.Sleep会被重定向为js.Sleep，但time.After、time.Ticker仍可用（底层走的是 JSsetTimeout） - 任何涉及
CGO_ENABLED=1的构建都会失败，WASM 不支持 C 互操作
调试时别信浏览器 DevTools 的“WASM 线程”面板
Chrome / Firefox 的 WASM 线程调试器显示的是底层 V8 的线程调度，和 Go 的 goroutine 完全无关。你看到的“多个线程”其实是 JS 引擎在做 GC 或编译优化，不是你的 go func()。
真实 goroutine 状态只能靠 runtime.NumGoroutine() 打印，或用 pprof 导出（需额外启用 HTTP server —— 但注意，这又回到上一条限制：WASM 里 http.ListenAndServe 会 panic）。
- 最有效的调试方式是混用
fmt.Println和js.Global().Get("console").Call("debug", ...) -
panic不会打印堆栈到控制台，除非你在main()外层包一层recover并手动输出 - Source map 支持极弱，Go 1.21+ 生成的
.wasm.map文件浏览器基本不识别，别花时间配 webpack 或 vite 的 WASM source map 插件
WASM 的 Go 运行时是单线程事件循环模型，所有 goroutine 都在同一个 JS microtask 中协作调度——这点和本地 Go 完全不同，也是多数阻塞逻辑失效的根本原因。
