WebAssembly 是将高密度计算从 JavaScript 引擎中剥离以实现接近原生性能的加密执行环境，关键在于端到端线性内存运算、零拷贝接口、JS 主导内存管理及 Web Crypto 回退机制。
WebAssembly 不是用来“卸载”算法的搬运工，而是把高密度计算从 JavaScript 引擎的解释、类型检查和 GC 压力中彻底剥离出来，在接近原生的环境中稳定执行。真正起效的关键，是让加密逻辑在 Wasm 线性内存中完成端到端运算，避免 JS 层反复拷贝、构造和等待。
选对算法并确保纯计算性
前端加密不能只图快，更需安全与确定性。适合迁移到 Wasm 的原始加密算法需满足：无系统调用、无线程依赖、无随机时间源、所有输入输出完全可控。推荐使用：
- SHA-256 / SHA-512（哈希校验、密码派生）
- AES-GCM / AES-CBC（密钥固定、IV 显式传入）
- Argon2id（需预分配盐、迭代次数硬编码或由 JS 控制）
- BLAKE3（极快、内存友好、适合大块数据）
禁用任何依赖 std::time、rand::thread_rng() 或全局静态缓冲区的实现。熵必须由 JS 侧通过 crypto.getRandomValues() 提供并显式传入。
内存必须由 JS 主导分配与复用
Wasm 没有自动内存管理，JS 才是内存生命周期的唯一负责人。错误做法是每次加密都 new Uint8Array(1024*1024)；正确路径是：
- 初始化后保留
instance.exports.memory实例 - 用
new Uint8Array(memory.buffer)创建长期视图 - 为明文、密钥、IV、输出分别预留固定 offset（如 0x0000、0x1000、0x2000）
- 每次调用前仅用
.fill(0, start, end)清空相关区域，不重建视图
这样可消除 90% 以上的 GC 压力，实测 AES-256-CBC 吞吐量提升 3–4 倍。
导出函数必须是零拷贝纯接口
Wasm 函数签名里不能出现数组、字符串或结构体——所有参数必须是 i32（表示内存偏移）和 i32（表示长度）。例如：
#[no_mangle]
pub extern "C" fn aes_gcm_encrypt(
plaintext_ptr: i32,
key_ptr: i32,
iv_ptr: i32,
out_ptr: i32,
len: i32
) { ... }
JS 侧调用时只需：
const ptr = 0x0000; plaintextView.set(inputBytes, ptr); keyView.set(keyBytes, 0x1000); ivView.set(ivBytes, 0x2000); wasmInstance.exports.aes_gcm_encrypt(ptr, 0x1000, 0x2000, 0x3000, inputBytes.length);
整个过程无隐式复制，数据始终在共享内存中流转。
必须内置 fallback 到 Web Crypto API
不是所有环境都支持 Wasm 加密：Safari 16.3 及更早版本不支持 WebAssembly.Global；某些企业浏览器禁用 Wasm；低配设备加载 .wasm 文件延迟明显。因此：
- 首次加载时检测
WebAssembly.validate(bytes)和typeof crypto.subtle !== 'undefined' - 若 Wasm 不可用，直接调用
crypto.subtle.encrypt({ name: 'AES-GCM' }, key, data) - 密钥导入逻辑保持一致：Wasm 使用 raw bytes，Web Crypto 使用
importKey('raw', keyBytes, ...)
用户无感知，安全边界不降低，性能上限有保障。
