Go 编译 WebAssembly 需设 GOOS=js GOARCH=wasm，主函数末尾须阻塞（如 <-make(chan struct{})），用 syscall/js 谨慎类型转换，预分配内存、避免热循环日志，使用匹配 Go 版本的 wasm_exec.js，且不支持热更新。
Go 本身没有“框架”能直接集成 WebAssembly —— 它靠的是标准工具链和 syscall/js 手动桥接，不是像 React/Vue 那样插件式接入。 想在浏览器里用 Go 做高性能计算，核心是绕过 JavaScript 引擎瓶颈，把密集逻辑（比如图像滤镜、密码学、数值模拟）编译成 main.wasm，再由 JS 加载调用。下面直说关键实操点。
编译时必须设对 GOOS 和 GOARCH
Go 不会自动识别你要编译成 WebAssembly；漏掉环境变量就生成本地可执行文件，根本跑不起来。
-
GOOS=js GOARCH=wasm是硬性前提，不能只写一个 - Windows 用户用
set GOOS=js和set GOARCH=wasm，别用 Linux/macOS 的export - Go 版本必须 ≥ 1.11，但建议用 1.22+：旧版
syscall/js对 Promise、SharedArrayBuffer支持弱，容易卡死或报cannot load wasm binary
main 函数末尾的阻塞必须存在
Wasm 模块加载后，Go runtime 会随主线程退出而销毁 —— 如果没拦住，函数注册就失效，JS 调用时会静默失败或报 greetFromGo is not a function。
- 用
<-make(chan struct{})最简洁，比select{}更明确阻塞意图 - 千万别在
main()里直接return或跑完就 exit，那等于告诉浏览器“我干完了，可以卸载了” - 如果要做初始化后释放资源（比如预加载大数组），得用 goroutine 启动，主 goroutine 仍需保持存活
与 JavaScript 传参/取返回值要小心类型转换
syscall/js 不做自动类型推导，JS 传数字过来默认是 float64，字符串是 js.Value，直接用 .Int() 或 .String() 可能 panic。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 检查参数长度：
if len(args) - 数字转 int：先
args[0].Float()再int()，避免.Int()对非整数输入 panic - 返回复杂结构（如 slice）要手动转成 JS 数组：
js.ArrayOf(js.ValueOf(1), js.ValueOf(2))，不能直接 return Go slice - DOM 操作失败不报错，加
if !el.IsNull() { el.Set("value", "ok") }判断节点是否存在
性能敏感场景必须避开 GC 和同步阻塞
浏览器中 Go 的 GC 会暂停整个 Wasm 实例，大数组分配、频繁小对象创建会导致明显卡顿；且所有 JS 互操作都是同步的，一旦 Go 函数耗时 >16ms，页面就掉帧。
- 预分配内存池：用
make([]float64, 0, 10000)初始化 slice，复用而非反复 make - 避免在热循环里调用
js.Global().Get("console").Call("log", ...)，日志全打到 JS 侧会拖慢 5–10 倍 - 真要长时间计算（如 >100ms），拆成多个小任务，用
js.Global().Get("setTimeout").Invoke(...)让出控制权 -
wasm_exec.js必须用$(go env GOROOT)/misc/wasm/wasm_exec.js当前 Go 版本配套的那份，混用不同 Go 版本的脚本会导致runtime: out of memory
最常被忽略的是：Wasm 模块加载后无法热更新，改了 Go 代码必须刷新整个页面；开发时建议用 go:generate 自动复制 wasm_exec.js 并 watch main.go 触发重编译，不然改十次代码手点五次刷新，效率直接归零。
