好，上一篇我讲了"寄生式"JIT 的思路——不在 Go runtime 的地盘上硬刚，而是搭个小帐篷在旁边。现在我们来深入看看这个帐篷是怎么搭的。
wazero 是什么？
简单说：它是纯 Go 写的 WebAssembly 运行时。零依赖，不需要 CGO，没有外部库。
这有什么了不起的？让我用一个具体例子解释。
想象你写了一个 Go 程序，突然想让它能运行一段用 Rust 写的代码。正常情况下你会怎么做？用 CGO 调用 C 库，然后那个 C 库再调用 Rust？光是想想 cross-compilation 的噩梦我就头疼——你需要 GCC，需要配置不同平台的工具链，需要处理 glibc 和 musl 的区别... 部署到 Alpine 容器时突然崩溃，因为你是在 Ubuntu 上编译的。
wazero 解决了这一切。你把 Rust 代码编译成 Wasm 模块，然后用 wazero 在 Go 程序里直接加载运行。不需要 CGO，不需要外部依赖，只要你能 go build，你就能运行 wazero。
两种模式：Interpreter vs Compiler
wazero 提供了两种运行模式，这很重要：
1. Interpreter（解释器）：逐条执行 Wasm 指令。慢一些，但全平台支持——哪怕是 riscv64 这种冷门架构也能跑。
2. Compiler（编译器）：AOT 编译，在加载时就把 Wasm 编译成机器码。性能高 10 倍甚至更多。
对于我们说的"寄生式 JIT"场景，Compiler 模式是关键。因为我们的目的本身就是加速，如果用解释器模式，可能还不如直接跑 Go 原生的慢。
为什么它适合做"防火墙"？
回到我们的宿舍比喻。wazero 为什么能在宿管阿姨（Go runtime）眼皮底下偷偷煮火锅？
三个原因：
1. 沙盒隔离：Wasm 模块运行在一个完全隔离的内存空间里。它不能直接访问 Go 的内存，不能随意调用系统调用，一切行为都在控制之下。
2. Host Functions：你可以精确控制 Wasm 模块能做什么。通过 NewHostModuleBuilder 导出 Go 函数给 Wasm 调用，比如只允许它做纯计算，不允许它碰文件系统。
3. 零侵入：因为 wazero 是纯 Go 实现的，它生成的机器码对 Go runtime 来说是"合法"的。runtime 看到的是一段普通的 Go 代码在执行，不知道里面其实已经切换到了 Wasm 编译的机器码。
一个关键细节：内存管理
在上篇文章里我提到，JIT 代码必须是 pointer-free，因为 Go 的 GC 看不到 Wasm 里的指针。wazero 如何处理这个？
Wasm 模块有一块线性内存（linear memory），通过 m.Memory().Read()/.Write() 访问。这块内存是脱离 Go GC 管理的——就像你用 malloc 申请的 C 堆内存一样。
这意味着你可以放心地把数据 spill 到这块内存里，GC 不会扫描它，也不会误删。代价是：你自己管理这块内存的生命周期。
实际用起来怎么样？
wazero 不是玩具项目。它由 Tetrate（Envoy/Istio 的主要贡献者）维护，Dapr、Trivy、Mosn 这些知名项目都在用。2024 年发布了稳定的 v1.0。
在我们的寄生式 JIT 场景里，它的价值在于：它已经解决了所有困难的问题——跨平台、安全隔离、高性能编译——你只需要把热点 trace 翻译成 Wasm 喂给它。
这算不算理解了？
让我检验一下。如果给大一新生解释，我会说：
wazero 就像一个"万能翻译机"。你把任何语言（Rust、C、C++）写的代码编译成一种通用格式（Wasm），然后 wazero 能把它翻译成你电脑能直接运行的机器码。最重要的是，它完全用 Go 写成，所以 Go runtime 觉得它是"自己人"，不会阻止它运行。
这样解释，你听懂了吗？
#补充 #wazero #Wasm #深度解析 #费曼风格