Go编译的WASM需配套官方wasm_exec.js才能运行，因其提供go.run等全局方法且与Go版本强绑定；直接加载main.wasm会报“go.run is not a function”，因胶水代码未执行或顺序错误。
Go 编译出的 wasm_exec.js 为什么找不到 run 方法？
Go 1.11+ 默认生成的 WASM 输出是 main.wasm，但不带运行时胶水代码——你得自己加载 wasm_exec.js，且必须用 Go 官方提供的那一份，不能手写或复用旧版。
-
wasm_exec.js位置在$GOROOT/misc/wasm/wasm_exec.js，每次升级 Go 都要重新拷贝，它和 Go 版本强绑定 - 浏览器中直接
fetch加载main.wasm后调用WebAssembly.instantiateStreaming是行不通的：Go 的 WASM 依赖go.run入口，而该函数由wasm_exec.js注入全局作用域，不是 WASM 导出的 - 常见错误现象：
TypeError: go.run is not a function，本质是wasm_exec.js没执行，或执行顺序错（比如在main.wasm加载前就调了go.run）
Go 的 GOOS=js GOARCH=wasm go build 输出为什么不能直接当普通模块用？
Go 编译出的 WASM 不是标准 ESM 模块，它没有 export，也不支持 import，整个生命周期靠 wasm_exec.js 协调，所以不能 import { something } from './main.wasm'。
- 输出文件只有
main.wasm（二进制）和配套的wasm_exec.js（JS 胶水），没有.d.ts，没有default export - 若想暴露函数给 JS 调用，必须用
syscall/js.FuncOf显式注册，例如：js.Global().Set("add", js.FuncOf(func(this js.Value, args []js.Value) interface{} { return args[0].Int() + args[1].Int() })) - 所有注册到
js.Global()的函数，JS 端才能通过window.add(1, 2)调用；没注册的 Go 函数，JS 完全不可见
为什么 fmt.Println 在浏览器里不输出到控制台？
Go 的 fmt 默认写到 os.Stdout，而 WASM 环境下 os.Stdout 被重定向到了 console.log，但有个关键前提：wasm_exec.js 必须已加载并完成初始化。
- 如果 JS 主逻辑在
wasm_exec.js加载完成前就执行了 Go 代码（比如通过init函数提前触发），fmt输出会静默丢失 - 调试建议：在 Go 里加一句
js.Global().Get("console").Call("log", "Go is ready")，确认 JS 运行时已就位再跑业务逻辑 - 性能影响：频繁
fmt.Println会触发大量跨语言调用，比原生 JSconsole.log慢一个数量级，生产环境建议关掉或重定向到自定义缓冲区
如何让 Go WASM 和现有前端工程（如 Vite/React）共存？
别把 Go 当“库”塞进构建流程，它更像一个独立运行时插件——最稳的方式是把 main.wasm 和 wasm_exec.js 当静态资源托管，JS 主应用按需加载。
立即学习“go语言免费学习笔记（深入）”；
- Vite 中可将
wasm_exec.js放到public/下，用await import('/wasm_exec.js')动态加载（注意：必须用完整路径，不能相对路径） - 避免在
index.html里直接<script src="wasm_exec.js"></script>，否则可能和打包工具的模块解析冲突 - 容易踩的坑：Vite 的
base配置会影响fetch('main.wasm')的路径，务必显式指定完整 URL，例如fetch('/assets/main.wasm')，而不是fetch('main.wasm')
WASM 不是“把 Go 代码扔进浏览器就行”，它是 Go 运行时 + JS 胶水 + 浏览器 WebAssembly 引擎三方咬合的结果。任何一环版本不匹配、加载顺序错乱、路径没对齐，都会卡在黑屏或报错。最常被忽略的，其实是 wasm_exec.js 和 main.wasm 必须来自同一版 Go 工具链——混用就会出现奇怪的符号缺失或 panic 信息无法解码。
