WebAssembly 不会取代 JavaScript，二者是协作关系；Wasm 无 DOM 访问能力，纯计算任务更高效，JS 负责 I/O 和 UI；调用需通过 instantiateStreaming 加载并检查导出函数，注意内存泄漏。
WebAssembly 不会取代 JavaScript，它俩是搭档，不是对手。 你写一个图像滤镜功能，用 JavaScript 做 UI 控制和按钮响应，用 WebAssembly 处理像素计算——这才是真实项目里最常见、最合理的分工。
为什么不能直接用 WebAssembly 操作 DOM？
WebAssembly 标准本身不提供任何浏览器 API 访问能力，document.getElementById、addEventListener、fetch 这些全不可用。它运行在沙箱中，只能访问自己线性内存（WebAssembly.Memory）和通过 JavaScript 显式传入的函数。
- 试图在 Wasm 里直接调 DOM → 浏览器报错：
ReferenceError: document is not defined - 所有 DOM 更新必须由 JavaScript 主导，Wasm 只负责“算完把结果交出来”
- 哪怕你用 Rust +
wasm-bindgen，生成的 JS 胶水代码也绕不开document调用
什么时候该把代码从 JavaScript 搬到 WebAssembly？
看这三点：是否纯计算、是否反复执行、是否已有成熟 C/Rust/Go 实现。比如：
- 实时音视频编解码（
ffmpeg.wasm）→ 合适；简单表单校验 → 不合适 - 游戏物理引擎（Box2D 编译为 Wasm）→ 合适；点击弹个
alert→ 绝对不合适 - 你团队已有一套 C++ 图像处理库 → 编译成
.wasm省事；新写一个排序函数 → JS 的Array.prototype.sort更快更稳
性能差异不是玄学：同个矩阵乘法，在 Chrome 中 JavaScript 耗时约 120ms，Wasm 耗时约 35ms，但 Wasm 加载+编译首次开销多出 ~15–30ms。高频小任务反而更慢。
立即学习“Java免费学习笔记（深入）”；
怎么安全地在 JS 里调用 Wasm 函数？
别手写 base64 字节码（如 "AGFzbQEAAAABBwFgAn9/AX8DAgEABwcBA2FkZAAACgkBBwAgACABags="），那只是 demo 玩意儿。生产环境请走标准流程：
- 用
rustc --target wasm32-unknown-unknown或emcc编译源码，输出.wasm文件 - 用
WebAssembly.instantiateStreaming加载（支持流式解析，比instantiate快） - 导出函数参数必须是基本类型（
i32/f64），字符串/数组需手动管理内存布局 - 务必检查
instance.exports是否包含预期函数名，否则运行时报TypeError: instance.exports.xxx is not a function
(async () => {
try {
const response = await fetch('math_utils.wasm');
const { instance } = await WebAssembly.instantiateStreaming(response);
const result = instance.exports.add(100, 200); // ✅ 正确调用
console.log(result); // 300
} catch (err) {
console.error('Wasm load failed:', err.message); // ❌ 避免静默失败
}
})();
最容易被忽略的一点：Wasm 模块一旦加载，就固定在内存里，不会自动 GC。如果你动态加载多个模块又不用了，得手动释放 WebAssembly.Module 和 WebAssembly.Instance 引用，否则内存泄漏比 JS 更隐蔽。
