最近我把一个维护了两年多的 Electron 桌面工具整个重构了一遍换成了 Rust Vue 的 Tauri 方案。重构之前安装包是 224MB重构之后安装包直接变成 4.7MB。说实话连我自己在打包完成的那一刻都愣了一下这体积缩得实在有点夸张。这篇文章就把我横评 Tauri、Wails、Flutter Desktop、Qt、Neutralino、Electron 这 6 种跨平台桌面方案的真实过程写出来包括体积数字、迁移细节、装坑记录以及最后我为什么选择了 Rust Vue。整个横评不是实验室数据是从实际项目里跑出来的你可以直接拿来做选型参考。这次横评的起因是我手上这个工具集成了 m3u8 视频播放、简单的桌面聊天、文件存储和消息通知。原本用 Electron 做得挺顺手但随着用户越来越多反馈集中在两个点上第一安装包太大下载安装太慢第二内存占用太高挂着不动也吃掉 400 多 MB。我心说不行得找替代方案。于是把市面上常见的跨平台桌面开发方案都拉出来试了一遍最终选择了 Tauri并且把整个迁移过程完整跑通。1. 为什么我把 Electron 应用换成了更轻的方案1.1 Electron 那 224MB 到底装了什么先说 Electon 的安装包为什么会这么夸张。Electron 的架构是“Chromium Node.js 你的前端代码”也就是说每一个用 Electron 开发的应用都会把一整套完整的 Chromium 浏览器内核打包进去。什么 V8 引擎、Blink 渲染引擎、GPU 进程、网络栈全部塞进安装包。你写的 Vue 代码其实只占几 MB剩下的基本都是 Chromium 的体积。同一个用户如果装了 5 个 Electron 应用那就相当于电脑里同时存在 5 份完整浏览器内核这还不算每个应用运行时的独立进程开销。224MB 这个数字听起来很大但对于 Electron 应用其实非常正常。一个带 Node 依赖、带图片资源、带播放器组件的应用打包成 NSIS 安装包基本就是 200MB 起。问题在 Windows 上尤其明显用户下载慢、安装慢还得等解压体验很差。更麻烦的是Electron 应用一旦跑起来默认每个窗口会开 GPU 进程、渲染进程、主进程内存轻松上 400-500MB如果代码里有内存泄漏那再加一个量级也不是没可能。这次横评里我专门盯着的指标就是安装包体积和运行内存Electron 在这两项上的成绩是最差的。1.2 6 种方案的横评标准是怎么定的既然要横评就不能只看体积。我这次定了几条硬指标安装包体积、运行时内存、开发体验、生态成熟度、前端技术复用率、打包复杂度。因为我的业务场景是 Vue 技术栈所以“前端代码能多大程度复用”是很有分量的加分项。Tauri 和 Wails 支持 WebView 方案理论上前端代码基本不用改Flutter Desktop 则是需要整套 Dart 重写Qt 要用 C 或 QMLNeutralino 只适合非常轻的场景。候选名单最终锁定为 6 个Tauri、Wails、Flutter Desktop、QtQML/C、Neutralino、Electron。PySide/PyQt 这次没有纳入主排名但在选型时顺手对比过后面会提一嘴。每一项我都用同一个“m3u8 播放 桌面聊天”的需求去试能跑通就记录数据跑不通的地方直接记录坑点。这样下来得到的结果比看文档参数要真实得多。2. 6 种跨平台桌面方案的真实表现2.1 TauriRust 后端的激进派Tauri 用的是“Rust 后端 系统 WebView 渲染前端”的架构。Windows 上它调用 WebView2也就是微软基于 Chromium 内核内置的运行时macOS 上调用 WKWebViewLinux 上调用 WebKitGTK。因为不打包完整的 Chromium所以安装包就只有 Rust 二进制和前端静态资源体积自然小得离谱。我这次重构出来的 4.7MB 安装包里面包括了一个约 3MB 左右的 Rust 可执行文件加上几百 KB 的前端 dist 资源再经过 NSIS 压缩后的结果。打包带过来的前端资源其实非常小因为 Vue 应用编译后本身就是纯静态文件JS/CSS 加起来 1MB 都不到。Tauri 的组合是 Rust 前端框架。Rust 侧负责系统能力调用比如文件系统读写、Shell 调用、系统通知前端侧负责界面和交互。Tauri v2 的架构里Rust 通过 tauri::command 宏暴露给前端调用前端用 tauri-apps/api 的 invoke 和 Rust 通信。这套通信机制比 Electron 的 IPC 更干净性能也没得说。实际体验下来播放 m3u8 视频时 Tauri 的表现和 Electron 基本没有差别因为渲染用的都是 Chromium 内核只是 Tauri 借的是系统的 WebView。内存占用则低了很多同样的界面和播放任务Tauri 大约 120MB 左右Electron 稳定在 350MB 以上。如果担心 Rust 学习曲线可以放心的是我这个项目里 Rust 侧实际编写的代码只有 300 多行基本都是命令注册、文件操作、系统通知这类样板代码。真正复杂的业务逻辑还是在 Vue 里写Rust 只是一个高效的“系统能力适配层”。2.2 WailsGo 后端的低门槛路线Wails 的思路和 Tauri 非常像也是系统 WebView 前端框架只是后端语言换成了 Go。安装包体积同样能做到很小我实测一个简单的 Vue 项目打包出来大约是 12MB 左右比 Electron 小了一个量级但比 Tauri 还是大一点因为 Go 的运行时和二进制本身比 Rust 的轻量级二进制要大一些。Wails 的开发体验有一个亮点它支持 Go 和前端之间的双向调用而且 Go 的写法和调试在遇到简单业务时非常快。如果团队本身就是 Go 技术栈Wails 会非常顺手。我这次也用了 Wails 跑通同样的 m3u8 播放器步骤几乎和 Tauri 一样——用 Wails CLI 初始化的 Vue 模板在 v2 里已经很成熟把前端 build 后的 dist 目录交给 Go 二进制宿主即可。缺点是 Go 生态里可用的桌面级系统 API 相对少真到了需要底层能力的时候还是要回去写 CGO那就比较痛苦了。Wails 适合什么场景呢小团队、内部工具、Go 后端顺手做桌面壳。如果追求极致体积或者需要调用 Windows API 级别的底层能力Wails 不是最优解。2.3 Flutter Desktop界面自绘的那一套玩法Flutter Desktop 在跨平台方案里属于“自绘引擎”路线。它不走 WebView也不用系统原生控件而是用 Flutter 引擎自己渲染整套 UI。这意味着界面跟平台无关像素级一致。在 Windows 和 Linux 上Flutter Desktop 的安装包一般是 50MB 到 80MB 这个量级比 Electron 好但比 Tauri、Wails 差。原因是 Flutter 自带的引擎库flutter_windows.dll、icudtl.dat 等固定在那里体量就是几十 MB 起步。Flutter Desktop 的 UI 表现力确实强动画流畅度也不错如果你的产品需要非常自定义的界面比如播放器、仪表盘、数据可视化Flutter 会很出彩。但代价是前端技术栈完全不能复用Vue 代码基本废掉需要拿 Dart 重写。我试过把聊天列表和视频播放器用 Flutter 重写开发效率明显低于 Vue因为 Dart 的 UI 代码写起来比 HTML/CSS 直接但调试和布局的直观程度还是不如浏览器开发者工具。还有一个点需要留意Flutter Desktop 的插件生态比移动端差很多很多系统级能力要自己写 platform channel 调原生代码这对小团队来说成本不低。2.4 Qt/QML老牌原生派稳定但不轻松Qt 是一个真正“原生”跨平台方案C/QML 写完编译出的程序性能极好稳定性也是一线水准。安装包体积看你是静态编译还是动态链接动态链接的话可能就 30-50MB但用户机器上需要装 Qt 运行库静态编译体积会涨到 80MB 以上省去运行时依赖。Qt 在 Windows/Linux/macOS 的适配都很好文件系统、进程管理、网络、多媒体都有对应模块特别适合做工具类或工业级软件。但它的问题也很明显开发门槛高。如果你没有 C 功底直接用 QML 写界面虽然简单但是要和 C 业务逻辑对接就会涉及 QObject、信号槽机制、类型注册这些概念。我这次横评在 Qt 上的尝试其实是浅尝辄止因为用了一个下午才搭好环境写完一个界面雏形之后果断放弃了。Qt 适合专业人员或长期投入的产品不适合“从 Electron 里快速逃出来”的场景。2.5 Neutralino只想要个轻量壳子Neutralino 是个非常冷门但很有意思的方案。它做的事情比 Tauri 更简单甚至不捆绑任何后端运行时直接利用系统原生的 WebView 去加载本地前端文件然后通过一套轻量 API 来做文件、窗口、系统命令等操作。安装包可以做到 2MB 左右比 Tauri 还小。为什么这么小因为 Neutralino 甚至连一个可执行文件都做成了最精简的壳。但它的问题在于能力太弱。Tauri 的 Rust 后端能做各种复杂的事情而 Neutralino 的那些 API 只适合几十行代码的小工具。我做 m3u8 播放器的时候发现它的窗口控制和系统通知 API 可用但真要做一个带后端的复杂应用生态完全不够看。Neutralino 适合那种“我只是想让一个网页变成桌面小工具”的轻需求超过这个范围就很难受了。2.6 Electron它依然是生态底座的“参考答案”横评到最后还得把 Electron 本身拿出来说一句公道话。Electron 虽然体积大、内存高但它是跨平台桌面领域生态最完整的那个。任何一个第三方 SDK 都会优先考虑支持 Electron机器码模块、打印机驱动、硬件 SDK、播放器内核几乎都有现成封装。用 Electron 做桌面应用你大概率能在 npm 上找到所有需要的库。Tauri 和 Wails 的生态目前还差很远Rust 侧的很多能力需要自己封装前端侧倒是能复用大量 npm 包但关键的系统级集成还是得靠手写。Electron 的调试工具链也更成熟Chrome DevTools 直接可用崩溃上报、自动更新、应用签名这些方面都有成熟方案。所以如果你的应用依赖大量第三方原生能力或者团队没有后端能力Electron 依然是稳妥的选择只是你心里得清楚那 200MB 体积和内存消耗是“买生态”的代价。2.7 横评速查表方案技术栈安装包体量运行时依赖内存体验前端复用上手难度适合场景ElectronJS Chromium150-250MB自带 Chromium高100%低复杂应用、成熟生态TauriRust 系统 WebView2-10MB系统 WebView中低100%中追求体积和内存的正式应用WailsGo 系统 WebView10-20MB系统 WebView中低100%中低Go 团队、内部工具Flutter DesktopDart 自绘引擎40-80MBFlutter 引擎中需重写中强 UI 定制、动画Qt/QMLC/QML30-80MBQt 运行库/静态低需重写高工业级原生应用Neutralino原生 WebView1-3MB系统 WebView低100%低极轻量小工具3. Tauri 实战从 Electron 迁移到 4.7MB 的完整过程3.1 迁移动线Vue 侧代码几乎不用动你要有一个预期从 Electron 迁到 Tauri前端代码基本是“原封不动”的。Vue 项目本身是用 Vite 建的这个套路在 Tauri 里是被一等公民支持的。Tauri CLI 初始化时直接选 Vue TypeScript 模板然后把 Electron 项目里的 src 目录、路由配置、状态管理、组件都搬过来依赖装好项目就能跑起来。实际上我在迁移时唯一需要处理的是环境判断。Electron 里用 window.electronAPI 或者 require(electron) 的地方要改成 Tauri 的 tauri-apps/api 里的 invoke不涉及桌面 API 的纯前端代码比如 m3u8 播放的 hls.js 封装、聊天列表渲染、路由逻辑完全没动。具体到 m3u8 播放器Tauri 的 WebView 在前端就是一个标准浏览器环境hls.js 直接能用video 标签直接能用。原先在 Electron 里播放 m3u8 的所有逻辑迁移过来零改动。唯一的注意点是如果视频流涉及跨域请求你需要在 Tauri 的 CSP内容安全策略配置里把对应域名放行这个在 tauri.conf.json 里加一句话就行比 Electron 那种默认宽松的 CSP 管理起来更清晰。3.2 Rust 侧的能力补齐Rust 侧在这个项目里做的事情不多但都是 Electron 里原本依赖主进程完成的事读取本地配置文件、监听系统通知、获取系统信息、解析文件路径。Tauri 的 IPC 模型很简单我直接用 #[tauri::command] 宏定义了几个函数然后在前端用 invoke 调用。代码大概长这样// src-tauri/src/lib.rs use tauri::Manager; #[tauri::command] fn read_config(path: String) - ResultString, String { std::fs::read_to_string(path).map_err(|e| e.to_string()) } #[tauri::command] fn send_notification(app: tauri::AppHandle, title: String, body: String) { app.notification_builder() .title(title) .body(body) .show() .unwrap_or(()); }对应的前端调用方式import { invoke } from tauri-apps/api/core; const config await invokestring(read_config, { path: app.conf });Tauri 2 的 API 名和 v1 有差异官方文档目前也是以 v2 为主建议新项目直接用 v2 模板不要再回看 v1 的示例了免得被老代码误导。Rust 侧写完代码后用 cargo check 检查一遍没有类型问题再跑 tauri dev 启动热更新开发模式前端改动会像 Vite dev server 一样自动刷新开发体验其实和 Electron 很接近了。3.3 关键配置与打包体积控制打包体积从 224MB 缩到 4.7MB配置上是有讲究的。首先 tauri.conf.json 里的 build 配置决定了前端产物怎么进 WebView{ build: { beforeDevCommand: npm run dev, devUrl: http://localhost:5173, beforeBuildCommand: npm run build, frontendDist: ../dist }, bundle: { active: true, targets: [nsis], identifier: com.example.desktop, icon: [icons/icon.ico] }, app: { windows: [ { title: 播放器工具, width: 1200, height: 800, resizable: true } ] } }beforeBuildCommand 会先执行 npm run build把 Vue 编译成静态文件放到 distfrontendDist 指向这个目录tauri build 会调用 Rust 编译器把 Rust 后端编译成 release 二进制再把 dist 里的静态资源嵌入二进制。我用的 Rust 编译参数是默认的 release profile就够了。如果想进一步优化体积可以在 Cargo.toml 里开启 opt-level z 和 lto true能再压一点二进制体积但增量有限而且会牺牲一点编译速度非强迫症不建议折腾。NSIS 是 Windows 安装包的默认打包器它对可执行文件和资源做了压缩所以最终 4.7MB 是“Rust 二进制压缩 前端资源压缩 安装脚本”的总和。整个安装包被 WebView2 拒绝打进安装包因为 Windows 10/11 系统里基本已经内置 WebView2 运行时即便用户的机器上没有Tauri 的 NSIS 配置也可以选择在安装时静默下载但那样体积会增加一点点。默认情况下Tauri 打包出来的是不包含 WebView 运行时的这正是体积优势的核心原因。4. 常见问题与避坑实录4.1 系统 WebView 依赖的坑Tauri 的 4.7MB 不是白来的它有一个前提用户的系统里有可用的 WebView 运行时。Windows 上就是 WebView2macOS 上用 WKWebViewLinux 上是 WebKitGTK。这三个里头Windows 的情况最需要留意。Windows 10 较老版本、Windows Server、以及很多精简版系统可能不带 WebView2. 如果应用在用户机器上启动后白屏九成是这个原因。解决办法是在打包配置里选择 WebView2 的安装策略Tauri 支持 offline installer 和 bootstrapper 两种模式前者会把完整的 WebView2 安装包塞进去体积会多出 100 多 MB那就失去意义了后者是一个很小的引导程序在线静默安装体验更好。在 Linux 上打包还需要编译 webkit2gtk非常吃系统依赖。我一开始在 CentOS 7 的服务器上编译 Linux 版直接被 GLib 版本卡死后来换了 Ubuntu 20.04 的构建环境才顺利。如果你要发布 Linux 版建议直接上较新的 Debian/Ubuntu 系环境并装好 libwebkit2gtk-4.1-dev、libappindicator3-dev 这些依赖别在太老的系统上折腾。4.2 打包阶段的高频报错这次横评和迁移过程中我踩了不少打包相关的坑这里整理一张速查表全是真实遇到过的现象常见原因解决办法Electron 打包 Linux 出现 fpm 报错fpm 的 Ruby 依赖缺失或版本不对先跑 gem update --system再重装 fpm或者直接用 electron-builder 的 AppImage 目标不经过 fpmvue-tsc 和 typescript 版本不匹配package.json 里 vue-tsc 1.8.27 配了 typescript 5.3.3 之类类型检查阶段报错统一升级到 vite 插件对应版本或者把类型检查命令从 build 流程里拆出来打包时跳过Electron 打包后内存持续增长纯前端代码内存泄漏主进程无法感知启动时加上 --expose-gc 参数在渲染进程里定时调用 global.gc() 并记录占用再定位泄漏组件Tauri build 提示 webview2 相关错误构建机环境缺少 WebView2 SDK安装 WebView2 SDK 或调整 bundle 里的 webviewInstallModeRust 编译报 linking withccfailedWindows 上缺 MSVC 构建工具安装 Visual Studio Build Tools选上“使用 C 的桌面开发”工作负载前端资源注入失败、白屏frontendDist 路径写错或 beforeBuildCommand 没正确生成 dist确认 npm run build 成功产出 dist且路径相对于 src-tauri 目录正确其中那个 Electron 内存排查的方法值得细说一下。应用启动时加上 --expose-gc然后在主进程设置一个定时任务轮询每个渲染进程的内存如果发现明显上涨就主动触发 global.gc()。这个操作能帮你区分“真实的垃圾没回收”和“引用的对象确实还活着”。我之前排查过一个聊天界面加视频播放器的 Electron 应用最后定位到是发消息后消息列表没有清理历史 DOM 节点导致内存不断上涨。这个问题后来在 Tauri 里因为界面依赖的组件库变了直接就消失了但排查思路本身对所有桌面应用都适用。4.3 什么人适合换什么人别折腾这次横评跑完我对“要不要从 Electron 换到 Tauri”这个问题有了比较明确的判断。如果你的应用核心是数据密集型或系统能力密集型比如需要在后台跑大量 Node 逻辑、需要调用大量原生模块那换到 Tauri 的收益不大反而会被 Rust 的复杂度和生态空缺拖累。如果你的应用主要是“Web 界面 少量系统能力”的形态比如播放器、聊天工具、内部管理后台、素材管理软件那 Tauri 几乎是完美的选择安装包小、内存低、Vue 代码能复用发布出去的版本用户体检非常好。另外说一句 PySide 的事。热词里有人把 Electron 和 PySide 放在一起比。PySide 的优势是 Python 生态适合做 AI 工具、数据处理工具的界面但打包体积也是 100MB 以上而且 Python 运行时跨平台分发老问题还在。如果你的项目是纯 Python 技术栈PySide 比 Electron 更值得考虑但如果你已经写了大量 Vue/React那 PySide 的迁移成本太高不值得。我自己的体会是跨平台桌面方案的选型本质上是“你要付出什么代价来换取什么节省”。Electron 的代价是体积和内存换来的是最省心的开发生态Tauri 的代价是要补一点 Rust 基础换来的是体面和轻量Flutter 的代价是前端重写换来的是完全可控的 UI。没有绝对正确的方案只有你公司或你个人技术栈适配的方案。这次把 224MB 的应用改造成 4.7MB 之后用户的下载安装体验提升非常明显。以前群里发新版本经常有人说安装包太大懒得下载现在 4.7MB 的新版本基本是群里 一下就瞬间下载完了。内存占用也从 400MB 降到 130MB 左右旧电脑上跑起来明显跟手了。我个人的项目现在默认新开的桌面应用直接走 Tauri 模板Rust 侧代码控制在 500 行以内超过这个规模才考虑引入更复杂的架构。如果你也在纠结 Electron 的体积问题建议先拿一个功能简单的页面在 Tauri 里跑一遍感受一下这套 RPC 模型和体积输出的实际效果再决定要不要全面迁移。