纯 javascript 正则在万级词库+gb文本下性能不足，因回溯无保护、字符串操作频繁触发gc；webassembly（rust+ac自动机）是解决主线程阻塞的刚性方案，需手动管理内存生命周期并规避simd兼容性问题。
纯 JavaScript 实现的敏感词过滤在万级词库 + GB 级文本场景下，indexOf 或正则遍历会卡顿明显，延迟常超 200ms；WebAssembly 不是“锦上添花”，而是解决响应阻塞的刚性路径。
为什么不能直接用 JS 正则做敏感词过滤
浏览器正则引擎（如 V8 的 Irregexp）对复杂模式回溯无保护，一个 .*?敏感词.*? 在恶意构造长文本时极易触发指数级匹配；更关键的是，JS 字符串操作（如 slice、substring）每轮都分配新对象，GC 压力随文本长度线性上升——实测 50MB 日志流处理中，GC 占比达 41%，主线程频繁暂停。
常见错误现象包括：
- 输入框粘贴大段文本后 UI 冻结 1–3 秒
- 过滤结果偶尔漏匹配（因超时被
setTimeout中断） - Chrome DevTools Performance 面板显示大量
Scavenger和MarkSweepCompact事件
Rust + wasm-pack 编译带 Aho-Corasick 的 WASM 模块
Aho-Corasick 是多模式匹配的黄金算法，适合敏感词这种“一次建树、多次查询”场景。Rust 实现可零成本抽象，且 wasm-pack 能自动处理内存导出与 JS 绑定。
实操要点：
- 在
src/lib.rs中用aho-corasickcrate 构建自动机，暴露build_automaton和find_iter两个函数，均标注#[wasm_bindgen] -
build_automaton接收&[&str]，返回一个AutomatonHandle（内部封装Box<ahocorasick></ahocorasick>），避免字符串拷贝到 WASM 线性内存 - 编译命令必须加
--target web：wasm-pack build --target web --out-dir pkg，否则生成的.wasm缺少 JS glue code - 禁用默认的
console_error_panic_hook（生产环境会暴露堆栈），改用cfg-if条件编译隔离调试逻辑
JS 端调用时必须手动管理 WASM 内存生命周期
WASM 没有 GC，Rust 分配的自动机构建内存不会自动释放，反复调用 build_automaton 会导致内存泄漏——这是最常被忽略的坑。
正确做法是：
- 在 Rust 端导出一个
drop_automaton函数，接收AutomatonHandle并调用Box::from_raw释放 - JS 端用
FinalizationRegistry注册清理回调：registry.register(automaton, handle, automaton)，确保即使开发者忘记调用drop_automaton，也能兜底回收 - 匹配时传入文本用
Uint8Array而非string，避免 JS → WASM 字符串编码开销；Rust 端用std::ffi::CStr直接读取内存视图 - 若需返回匹配位置，Rust 返回
Vec，JS 用Uint32Array接收并按步长 2 解析起止偏移
SIMD 加速只在 Chrome 120+ / Firefox 125+ 有效，别盲目开启
AVX2 指令集可让单次指令并行比较 32 字节，对固定长度关键词（如身份证号、手机号规则）提升显著；但 Safari 完全不支持 wasm_simd 提案，Edge 仅在 Canary 版本实验性启用。
落地建议：
- 编译时用
rustc --cfg=feature="simd"分条件编译两版 WASM：filter.wasm（基础版）和filter-simd.wasm（SIMD 版） - JS 加载前检测：
if (WebAssembly.validate(simdBytes)) { load("filter-simd.wasm") }，失败则降级 - SIMD 版本不要用于模糊匹配（如拼音、同音字），其向量化逻辑依赖精确字节对齐，容错性反而低于标量版本
真正难的不是编译出 .wasm 文件，而是让 JS 与 WASM 的边界内存行为可预测、可审计——尤其当敏感词引擎嵌入到编辑器或实时通讯组件中时，一次未释放的自动机可能让整个页面内存占用持续增长数小时。
