先说结论：做普通桌面应用，两个壳都行；但做要跟本地 AI 服务抢资源的桌面应用，账就变了——你的机器资源有限，壳多吃一口，模型就少吃一口。本文以一个本地优先的 AI 画布应用（React 节点画布 + 本地推理 + 素材管理）的选型为例，把这笔账和 Tauri 的坑一起讲全。
先算资源账：壳不能抢戏
Electron 自带一整个 Chromium 加 Node，空壳安装包奔着 100MB 去，运行时再起好几个进程吃内存。普通应用无所谓，AI 应用场景完全不同：本地跑图跑视频的模型本来就吃满显存内存，用户还同时开着浏览器和剪辑软件——壳自己先占几百 MB，就是在跟用户的模型抢饭吃。
Tauri 借用系统自带 WebView（Windows 的 WebView2、macOS 的 WKWebView、Linux 的 WebKitGTK），不打包浏览器内核，Rust 做后端。真实数字：一个功能已经很满的 AI 画布应用（画布、资产库、本地 ONNX 推理、MCP 服务全算上），Windows 安装包 35.4MB——换 Electron，光 Chromium 固定开销就差不多是这个数，业务代码还没开始算。
代价也要说清：借系统 WebView 不是白拿，跨平台渲染一致性要自己兜底。同一份 CSS 在 WKWebView 和 WebView2 上有小差异，Linux 的 WebKitGTK 相对滞后。强依赖最新 Chrome 特性（如 WebGPU 新 API）或要求三平台像素级一致的场景，Electron 的自带内核反而是优势。
真正拉开差距的：Rust 层能干脏活
连本地服务：实时拿本地模型服务的生成进度走 WebSocket，前端 JS 直连会撞浏览器的 Origin 校验和混合内容限制。把连接放进 Rust 层（tokio 加 tungstenite），原生层订阅事件再转发给前端，前端只管渲染进度条。
本地推理：轻量推理不想麻烦大模型服务时，用 ONNX Runtime 直接在 Rust 进程内调用。对比 Electron 时代常见的"打包一个 Python 环境当 sidecar"——体积、启动速度、用户机器环境的不确定性三座大山全免。代价是自己管好模型文件和线程，别把主进程拖死。
打包与更新：官方 updater 插件要求更新包签名，发布流水线一次出齐三平台安装包加签名文件，客户端验签后才装。独立开发者少维护一套自研更新逻辑，就少一堆半夜被用户喊"更新坏了"的时刻。
对外暴露能力：MCP 服务直接长在应用里（axum 起流式 HTTP），外部 Agent 可以连进来操作画布。放在原生层还有个安全红利：哪些目录能读、哪些操作只读，在 Rust 层统一收口，而不是散落在前端代码里。
什么时候选回 Electron
把话说全，四种情况毫不犹豫选 Electron：团队只有前端同学，没人能维护 Rust；强依赖 Chromium 一致性或新特性；产品形态是"套壳加大量现成 Node 包"，拼开发速度；应用不需要碰本地系统，纯粹网页桌面版——这种场景壳越透明越好。
选型小抄与最后一句
| 维度 | Tauri | Electron |
|---|---|---|
| 安装包 | 小（借系统 WebView） | 大（自带 Chromium） |
| 内存占用 | 低，单进程为主 | 高，多进程模型 |
| 后端语言 | Rust（门槛高能力强） | Node（上手快生态大） |
| 渲染一致性 | 依赖系统 WebView，要测 | 三平台同内核 |
| 本地系统能力 | 文件/进程/推理顺手 | 靠 Node 加原生模块拼 |
| 适合 | 本地优先、常驻、重系统交互 | Web 套壳、快速迭代 |
说到底，壳只是壳。AI 应用真正的竞争力在工作流和数据在谁手里。本地优先、常驻驻留、深度系统交互的应用，Tauri 的账算得过来；剩下的场景，选团队顺手的那个，别为技术偏好买单。
评论0