Go WASM模块必须阻塞main函数，否则运行时静默终止、导出函数失效；唯一可靠阻塞方式是select{}或for{}，因WASM无OS线程且调度器需持续运行。
Go 编译到 WebAssembly 本身不依赖“语言学习技巧”，而是依赖对 GOOS=js、GOARCH=wasm 构建流程和运行时约束的准确理解。盲目套用通用编程学习方法（如刻意练习、间隔重复）对提升 WASM 模块性能毫无帮助——真正影响效率的是内存管理方式、系统调用限制和 JS 交互模式。
为什么 main 函数必须阻塞且不能退出
Go 的 WASM 运行时要求 main 永不返回，否则整个模块会静默终止，所有导出函数失效。这不是 bug，而是设计使然：Go 的调度器需要持续运行以处理 goroutine 和回调。
- 错误写法：
func main() { fmt.Println("hello"); return }→ 执行完立即退出，后续 JS 调用exportedFunc无响应 - 正确写法：
func main() { http.ListenAndServe(":8080", nil) }或select {}阻塞 - 若仅需导出函数（无 HTTP 服务），用
syscall/js.CreateThread不可行（WASM 无线程），唯一可靠方式是select {}或for {}
syscall/js 是唯一合法的 JS 交互通道
Go WASM 无法直接访问 DOM 或调用 fetch，所有 JS 互操作必须通过 syscall/js 封装。任何试图绕过它的尝试（比如用 cgo、unsafe 直接读写内存）在浏览器中均被禁止。
- 导出函数必须注册到
js.Global()，例如：js.Global().Set("add", js.FuncOf(func(this js.Value, args []js.Value) interface{} { return args[0].Int() + args[1].Int() })) - JS 传入的
ArrayBuffer必须用js.CopyBytesToGo显式拷贝，不能直接用unsafe.Pointer转换 —— 否则触发 panic: “invalid memory address or nil pointer dereference” - 从 Go 向 JS 传递大数组时，优先用
js.TypedArrayOf而非 JSON 序列化，避免双序列化开销
内存分配必须显式控制，避免 GC 压力
WASM 实例共享一块线性内存，Go 运行时 GC 在浏览器中效率极低。频繁创建 slice、string 或 struct 会导致不可预测的卡顿，尤其在高频回调（如动画帧、音频处理）中。
- 复用
[]byte缓冲区：用make([]byte, 0, 4096)预分配并反复buf = buf[:0]清空，而非每次make([]byte, n) - 避免在导出函数中构造新
struct或map；若必须，提前在init()中初始化并复用 - 字符串转字节切片优先用
unsafe.StringHeader+unsafe.Slice（Go 1.20+），但需确保字符串生命周期长于 WASM 调用 —— 更安全的做法是 JS 传入Uint8Array，Go 直接操作
构建命令和 wasm_exec.js 版本必须严格匹配
go build -o main.wasm -gcflags="-l" -ldflags="-s -w" -o main.wasm 生成的二进制，与 $GOROOT/misc/wasm/wasm_exec.js 是强绑定关系。用错版本会导致 panic: syscall/js: call to non-existent function 或 undefined symbol: __syscall。
立即学习“go语言免费学习笔记（深入）”；
- 检查当前 Go 版本：
go version，然后复制对应版本的wasm_exec.js（例如 Go 1.22 → 用go-1.22/misc/wasm/wasm_exec.js） - 不要用 npm 包（如
webassembly-js）提供的 exec 文件，它们往往滞后或魔改 -
-gcflags="-l"禁用内联可减小体积，但可能影响某些 hot path 性能；实测中建议先保留默认，再按 profile 结果针对性优化
runtime: failed to create new OS thread —— 那不是你的代码错了，是你忘了 WASM 根本没有 OS 线程。 
