为什么我给 AI 应用选了 Tauri，而不是 Electron

为什么我给 AI 应用选了 Tauri，而不是 Electron

先说结论：做普通桌面应用，Tauri 和 Electron 都行；但做要跟本地 AI 服务抢资源的桌面应用，我选 Tauri。 原因跟“谁更先进”没关系，只跟一笔账有关：你的机器资源是有限的，壳多吃一口，模型就少吃一口。

我正在做的开源项目 AI Canvas 就是个典型场景：一个本地优先的 AI 画布应用，前端是 React 写的节点画布，后端要连本地 ComfyUI、跑本地小模型、管几万个素材文件。这篇文章聊聊我选型时的真实取舍，不吹不黑，Tauri 的坑也会讲。

一、先算账：AI 应用里，壳不能抢戏

Electron 的老问题大家都知道：自带一整个 Chromium + Node，空壳安装包就奔着 100MB 去了，运行时再起好几个进程吃内存。普通应用无所谓，但 AI 应用不一样：

• ComfyUI 在本地跑图跑视频，显存和内存本来就紧巴巴；
• 用户经常同时开着浏览器、剪辑软件、聊天工具；
• 这时候你的“壳”如果自己先占掉几百 MB，它就是在跟用户的模型抢饭吃。

Tauri 的思路是借用系统自带的 WebView（Windows 的 WebView2、macOS 的 WKWebView、Linux 的 WebKitGTK），不打包浏览器内核，Rust 做后端。实际数字：AI Canvas 现在功能已经堆得很满——画布、资产库、本地 ONNX 推理、MCP 服务都算上——最新版 Windows 安装包是 35.4MB。换成 Electron，光 Chromium 的固定开销就差不多是这个数了，业务代码还没开始算。

当然，借系统 WebView 不是白拿的：跨平台渲染一致性要自己兜底。同一个 CSS 在 WKWebView 和 WebView2 上的小差异、Linux 上 WebKitGTK 的相对滞后，都是真实成本。如果你的应用强依赖最新 Chrome 特性（比如 WebGPU 的新 API），或者要求三平台像素级一致，Electron 的“自带 Chromium”反而是优势。这一点后面还会说。

二、真正让我下决心的，是 Rust 后端能干“脏活”

体积只是入场券。我最后拍板 Tauri，是因为 AI 桌面应用有一堆“脏活”，放在 Rust 原生层比放在前端 JS 或 Node 主进程里顺手得多。

1. 连本地服务：把 WebSocket 从前端挪到原生层

AI Canvas 要实时拿 ComfyUI 的生成进度，走的是 WebSocket。如果让前端 JS 直接连 ws://127.0.0.1:8188，会接连撞上浏览器的 Origin 校验、混合内容（mixed-content）限制，换个环境就出幺蛾子。

我们的做法是：进度连接放在 Rust 层（tokio + tokio-tungstenite），原生层订阅 ComfyUI 的事件，再通过 Tauri 的 event 转发给前端。前端只管渲染进度条，不碰连接细节：

// 简化示意：原生层订阅 ComfyUI 进度，再转发给前端
#[tauri::command]
async fn watch_comfy_progress(app: AppHandle, server: String) -> Result<(), String> {
    let (mut ws, _) = tokio_tungstenite::connect_async(
        format!("ws://{server}/ws")).await.map_err(|e| e.to_string())?;
    while let Some(Ok(msg)) = ws.next().await {
        // 解析 executing / progress 事件
        let _ = app.emit("comfy-progress", parse_progress(&msg));
    }
    Ok(())
}

类似的脏活还有一串，全在 Rust 侧默默干：素材库用 SQLite（rusqlite）存元数据、扫盘算哈希给模型文件去重、图片无损重编码、监听文件夹变化。这些活的特点是量大、耗时、不能卡界面，用 Rust 写完编译成原生代码，不需要再打包一个 sidecar 进程去管生命周期。

2. 本地推理：进程内调用，而不是再拉起一个 Python

应用里有些小活不想麻烦 ComfyUI，比如本地语音转文字、轻量推理。这类能力我们用 ONNX Runtime 直接在 Rust 进程内调用（ort crate）。对比一下 Electron 时代常见的方案——打包一个 Python 环境当 sidecar——光是体积、启动速度和“用户机器上到底装了啥”的不确定性，就够喝一壶的。进程内调用没有这些问题，代价是你得自己处理好模型文件和线程别把主进程拖死。

3. 打包与更新：一套签名流程走完三平台

桌面应用绕不开自动更新。Tauri 官方的 updater 插件要求更新包带签名，发布时生成 latest.json 和各平台的 .sig 文件，客户端验签通过才装。AI Canvas 每次发版就是走这条流水线：Windows 的 NSIS/MSI、macOS 的 dmg、Linux 的 deb/rpm/AppImage 一次出齐。对独立开发者来说，少维护一套自研更新逻辑，就少一堆半夜被用户喊“更新坏了”的概率——这个体验，写过 Electron 自研更新的人都懂。

4. 对外暴露能力：MCP 服务直接长在应用里

现在 AI 工具之间流行用 MCP 互联。AI Canvas 的 MCP Server 就是用 axum + rmcp 在 Rust 侧起的一个 Streamable HTTP 服务，外部 Agent 可以直接连进来操作画布数据。把它放在原生层还有个好处：权限边界清楚——哪些目录能读、哪些操作只读，是在 Rust 层统一收口的，而不是散落在前端代码里。

三、那什么时候我会选回 Electron？

把话说全，免得变成站队文。以下情况我会毫不犹豫选 Electron：

• 团队只有前端同学，没有人能维护 Rust，出了问题没人兜底；
• 强依赖 Chromium 的一致性或新特性，比如重度使用 WebGL/WebGPU 且要求三平台表现完全一致；
• 插件生态优先，你的产品形态就是“套壳 + 大量现成 Node 包”，拼的是开发速度而不是体积和占用；
• 应用本身不需要碰本地系统，纯粹是网页的桌面版——这种场景壳越透明越好，选哪个都行，别纠结。

反过来，如果你的应用要长时间驻留、要跟本地服务和文件系统深度打交道、还要在意老机器能不能跑得动，那 Tauri 的账就算得过来了。

四、给选型留一张小抄

维度	Tauri	Electron
安装包	小（借系统 WebView）	大（自带 Chromium）
内存占用	低，单进程为主	高，多进程模型
后端语言	Rust（门槛高，原生能力强）	Node（上手快，生态大）
渲染一致性	依赖各系统 WebView，要测	三平台同一 Chromium
本地系统能力	文件/进程/推理都顺手	靠 Node 和原生模块拼
适合	本地优先、常驻、重系统交互	Web 套壳、快速迭代、纯前端团队

说到底，壳只是壳。AI 应用真正的竞争力在工作流和数据在谁手里——我做 AI Canvas 的出发点就是“创作，本该自由”：开放、本地、轻量，数据不出门、小巧不臃肿。Tauri 恰好是能把这几个词落地的那个选项，如此而已。

---

项目地址：https://github.com/Tenney95/AI-Canvas-tauri （目前 330+ stars，Tauri 2 + React 19，源码可见）

立个 flag 在这：star 到 10k，项目直接转 MIT 协议。 觉得这个方向有意思的，欢迎来拍砖。