写了五年 Rust，今天它的内存终于不是 4GB 了——wasm-pack v0.15.0 把 wasm64 这件事彻底落地了

配过图像处理或者大模型推理的前端工程师，大概都遇到过这个问题——Wasm 模块一跑起来，内存动不动就爆了。查了半天日志，发现根子不在代码，在 wasm32 那 4GB 的硬天花板。

这个 4GB 不是 Chrome 故意为难你，而是 wasm32 的线性内存用 32 位地址编码，最多只能寻址 4GB（65536 页 × 65536 字节）。对于 2026 年动不动就要跑个本地小模型、处理 4K 图像的工作流来说，4GB 不够用是常态。

实际上各浏览器的内存上限比 4GB 更保守。Chrome 通常限制在 256MB~1GB（桌面端），Firefox 宽松一些，Safari 移动端有时候只有几十 MB。如果你的 Rust 代码分配超过这个限制，运行时会直接 panic。

这个问题在 2026 年终于有了一个值得关注的进展——wasm-pack v0.15.0 在今年 5 月正式支持了 wasm64-unknown-unknown target。这意味着你可以让 Rust 编译出 64 位寻址的 Wasm 模块，不再受 4GB 限制。

具体来说，wasm-pack 0.15.0 做了三件事：

第一，--enable-memory64 自动追加到 wasm-opt 参数里，这是 wasm64 目标编译时打开内存64位扩展的关键链路。

第二，CARGO_TARGET_*_RUNNER 环境变量现在会根据目标三元组动态构造，确保不同 target 的运行器配置正确。

第三，--target 从 extra options 里提取出来，不再写死，让 wasm64 目标的构建流程和其他 target 一致。

用起来很简单：

rustup target add wasm64-unknown-unknown
wasm-pack build --target web --target wasm64-unknown-unknown

但这里有个坑：wasm64 目前是 Rust 的 Tier 3 平台，wasm-bindgen 还没有支持 wasm64。换句话说，你想用 #[wasm_bindgen] 跟 JavaScript 互通，现在还做不到——wasm-bindgen 是 wasm32 only。这意味着 wasm64 适合跑那些不直接调 JS 的纯计算密集模块，比如图像滤镜、大模型推理、数据处理管线；涉及 DOM 操作和复杂数据类转换的部分，仍然得靠 wasm32 + 编译时 --max-memory 扩展。

新版还顺手解决了另一个长期痛点：--panic-unwind flag。以前 Wasm 里的 panic 只能看到”trapped”，现在可以 unwind 出完整的堆栈跟踪。调试生产环境问题的时候，这个改变相当实用。

简单说：wasm64 让 Rust 在浏览器里的内存天花板从 4GB 提到了理论上 16EB（浏览器实际限制在几 GB 到十几 GB 不等），wasm-pack 把这个能力做进了标准构建流程里。wasm-bindgen 的 wasm64 支持是下一步，现在可以先在大计算量场景里用起来。

下一步：

• 纯计算模块（图像/视频/音频处理、数据分析）→ 立即尝试 wasm64
• 需要 JS 互操作（DOM、Fetch、复杂类型）→ 继续 wasm32，关注 wasm-bindgen 更新
• panic 调试 → 加上 --panic-unwind flag，生产环境也能拿到堆栈