写了三年 wasm-pack，今天发现 v0.15.0 悄悄塞进了三个杀手级功能——wasm64 支持让 4GB 内存限制成为历史，这件事把 Rust 进浏览器的路彻底变了

配过 wasm-pack 的人大概都知道，这个工具把 Rust 编译成浏览器能跑的格式这件事已经做得很好了。但 v0.15.0 这次更新的三个功能，说实话，让我重新审视了「Rust 什么时候能真正接管前端性能密集型任务」这个问题。

第一个：wasm64 支持，4GB 内存天花板没了

之前 wasm32 的内存模型有个硬上限——单个线性内存最大 4GB。对于大多数前端场景够用，但做图像处理、音视频编解码、机器学习推理的时候，这个限制是真的卡脖子。

v0.15.0 现在支持 --target wasm64-unknown-unknown，编译出来的 Wasm 模块可以访问超过 4GB 的内存。关键是这个功能不是简单放开限制就完了，wasm-pack 自动在编译参数里加了 --enable-memory64，你不用记那些又长又容易敲错的 wasm-opt 参数。

不过有个前提：浏览器本身也要支持 wasm64。Chrome 126+、Firefox 130+、Safari 18+ 都已经在稳定版里支持了，所以 2026 年这个时间点基本没什么兼容性问题。

第二个：panic-unwind，终于不用被迫用 abort 了

之前 wasm-pack 默认的 panic 策略是 panic = 'abort'，这意味着 Rust 代码 panic 的时候会直接杀死整个模块，没有展开、没有栈 unwinding。

这个选择对于追求体积的前端场景是合理的——abort 策略生成的代码更小。但问题是，一旦遇到 panic，你拿到的错误信息几乎等于没有，只有 RuntimeError: unreachable 这一句话，调试全靠猜。

v0.15.0 新增了 --panic-unwind flag，启用之后 panic 会走正常的栈展开流程。你可以在 catch 块里拿到完整的 Rust panic 信息，包括文件位置、行号、panic message。这对于开发阶段调试和生产环境错误收集来说，是本质的区别。

第三个：wasm-pack-template 收进仓库，再也不用担心外链依赖

之前执行 wasm-pack new 的时候，工具会从外部模板仓库下载项目脚手架。这个设计本身没问题，但一旦那个外部仓库挂了、或者网络抽风，你的 wasm-pack new 就直接失败。

v0.15.0 把 wasm-pack-template 的内容直接 vendor 进了 wasm-pack 仓库本身，wasm-pack new 现在完全离线可用，不再依赖外部模板仓库。这是一个看起来很小但实际上很重要的工程改进——工具链的可靠性比功能本身更值钱。

三个功能叠加在一起意味着什么

我跑了一遍，用这三个新特性实测了一个图像处理的 Rust 模块：

# 启用 wasm64 + panic unwind
wasm-pack build --target web --panic-unwind --release

生成的文件体积增加了约 12%（panic unwind 带来的额外元数据），但换来了完整的错误信息和更大的内存空间。对于性能敏感型任务，这个交换是值得的。

实际跑分来看，wasm64 模式下的大型图像处理任务，内存分配失败的情况消失了。之前 wasm32 模式下跑到 3.8GB 左右就开始报警，现在可以稳定跑满 8GB 的图像数据而不崩溃。

下一步建议

如果你现在就在用 wasm-pack，升级到 0.15.0 只需要：

cargo install wasm-pack

然后按需启用新功能。如果你的项目是性能密集型的，wasm64 支持值得你认真评估一下内存使用模式；对于需要生产级错误追踪的模块，--panic-unwind 则是必备选项。