不过，

用 Rust + WebAssembly 写了个字幕工具。文件全程不离开浏览器

一、直接说结果

我做了一个字幕工具台，支持多种主流字幕格式的互转、质量校验、文本规范化、元信息查看。整个应用没有后端字幕文件全程在浏览器里通过 WebAssembly 处理——不上传、不落地、零运维、免费托管。

• 主要引擎: subtitler
• 前端: React + TypeScript + Vite
• UI: Tailwind v4 + shadcn/ui
• 部署: GitHub Pages，通过 Actions 自动部署

听起来很常规？但里面有几个值得聊的工程决策。

二、使用者痛点：为什么选择 Rust + WASM 而不是纯 JS？其实，

字幕处理听起来简单。实际却是个坑很多的领域：

• 格式碎片化严重：SRT / VTT / ASS / SSA / MicroDVD / SubViewer / TTML / SBV / LRC / SAMI / MPL2 / SCC / EBU STL…，每种格式的时间戳语法、结构、样式表达都不一样。EBU STL 甚至是个二进制格式。
• 细节多：时间戳解析要处理逗号/点分隔符、帧率换算、Cue 间隔、嵌套样式标签、编码检测…怎么说呢，
• 已有成熟 Rust 实现：subtitler 已经把这些全做完了测试用例丰富，生产级别。

“我担心代码量大导致维护成本高。” —— 这正是我们采用 Rust + WASM 的根本原因： “复用”成熟的 Rust 库，而不是从头用 JS 重写解析逻辑。

三、整体架构：三层结构

┌─────────────────────────────────────────────────────┐
│ 浏览器 │
│ │
│ React + TS UI ──import──▶ subtitler_wasm.js │
│ │
│ │ │ │
│ │ File / paste ▼ │
│ │ subtitler.rs │
│ │ detect / convert │
│ │ validate / normalize │
│ ▼ ▼ │
│ Blob 下载 / 复制到剪贴板 ◀──────┘ │
└─────────────────────────────────────────────────────┘
└─ 静态部署

“我想让 UI 响应迅速，但又要兼顾性能。”——三层职责清晰，让每一层只做自己该干的事。

为什么要「薄包装 crate」，而不是直接编译 subtitler？

subtitler 本身已经支持 wasm 编译，它自带了 src/wasm.rs 暴露了 parse_subtitles。 convert_format,validate_subtitles 等函数。老实说，我为什么不在前端直接用这些？因为它们返回的是 serde_wasm_bindgen::JsValue  — 在浏览器里退化成 {…} Map，而不是普通对象/JSON。前端拿到 Map 后既不能直接解构。也不能  使用，更麻烦的是契约不清晰。

"我担心跨语言交互会产生大量 boilerplate。" —— 正因如此，我在项目内放了一个薄包装 crate wasm/​ 。它只做一件事：调子顶级 API，并把结果序列化成 JSON 字符串返回。按理说，

#
pub fn convert_subtitle -> String {
use subtitler::model::SubtitleFormat as _;let target_fmt = match format_from_name {
Some => f,None => return serde_json::json!({
"ok",false,"error",format!}).to_string,};let file = match subtitler::parse_bytes) {
Ok => f,Err => return serde_json::json!老实说，({
"ok",false,"error"。e.to_string
}).to_string,};话说回来，serde_json::json!({
"ok",true,"format",format_to_name,"count",file.subtitles.len as u32,"output"。file.to_string_with_format
}).to_string
}

"我要保证错误信息能被前端友好展示。" —— 所以所有函数统一返回契约： { ok:true,…data }|{ ok:false,error:string }