Electron与Tauri选型指南：2026桌面框架实践对比

2026年还在纠结 Electron 和 Tauri 的人，多半不是不知道框架，而是不确定自己的团队能承担哪一边的成本。我这两年帮团队做过桌面端选型，也盯着线上项目跑过内存和崩溃数据，说实话，这两者早就不是“一个包大一个包小”那么简单。Electron 的稳定性和生态依旧是桌面应用的主流答案，Tauri 却在包体和资源占用上杀出了一条更适合轻量工具的路。这篇文章我不打算复述文档，而是从实操视角把架构、性能、IPC、蓝牙、打包、升级、安全以及迁移成本放在一起盘一遍，最后给你一个可以直接抄的选型清单。

围绕 2026 年这个节点，我也会顺带把社区里问得最多的问题拆开讲：Tauri 在 Windows 上报 link.exe not found 怎么处理、Electron 主进程和渲染进程的 IPC 通信到底和 Vue 有没有关系、Electron 打包 Vue 项目时文件协议为什么会坑人、Electron 怎么访问蓝牙设备，以及 Tauri 项目升级版本时应该盯住哪些破坏性变化。

1. 两条技术路线的本质差异：Chromium 与系统 WebView 之争

1.1 Electron：一个自带浏览器的桌面框架

Electron 从架构上看其实非常简单：它把 Chromium、Node.js 和一套原生 API 打包进了你的应用。也就是说，无论用户电脑里装没装 Chrome、Edge，你的应用都自带一套完整浏览器内核。这套做法的好处是渲染一致性极强，你在 Windows 上看到的样式，到了 macOS 和 Linux 上也基本一致。坏处也很直观：安装包里默认躺着 80 到 100MB 左右的二进制文件，内存占用通常从 200 到 400MB 起步。

很多刚接触 Electron 的人会把注意力放在“几十 MB 的安装包”上，但真正让运维头疼的是内存。一个 Electron 应用往往不止一个渲染进程，主窗口、隐藏窗口、子窗口、GPU 进程、网络服务进程各占一块。哪怕你只写了一个空窗口，运行时也会看到好几个进程在内存里挂着。对现代 PC 来说这不致命，可如果你要面对的是政企单位、老旧电脑或者虚拟机里跑桌面的用户，内存大小直接决定能不能流畅运行。

Electron 的另一个特点，是它对前端工程师几乎零学习成本。你可以沿用 Vue、React、Vite、Webpack 这整套工程链，主进程和工具链仍然由你自己掌控。这也是为什么 Electron 这些年能一直保持生态热度，VS Code、Slack、Discord、Notion、飞书这类重度桌面应用，几乎都靠它撑住了复杂交互和动态 UI。

1.2 Tauri：借用系统内核的轻量方案

Tauri 的思路完全不同。它不用 Chromium，而是调用操作系统自带的 WebView：Windows 上基于 WebView2，macOS 上使用 WKWebView，Linux 上则是 WebKitGTK。渲染引擎由系统提供，应用本身只携带前端静态资源和一套 Rust 编写的后端壳子。这样一来，安装包可以从 Electron 的上百 MB 直接压到 3 到 10MB 级别，运行内存也能有非常明显的下降。

第一次用 Tauri 的人往往会被“体积小”震撼到，但真正值得关注的其实是内存分配方式。Tauri 的应用进程数量比 Electron 少很多，因为它不需要每开一个窗口就复制一份 Chromium 渲染进程。再加上 Rust 后端天然没有 Node.js 那套运行时开销，一个典型的 Tauri 工具在闲置状态下，内存可能只有 Electron 的 1/3 到 1/4。我见过最夸张的对比，是同一个 Vue 应用在 Electron 里跑到 260MB，换成 Tauri 后稳定在 70MB 左右。

代价也很明确：Tauri 渲染层的表现取决于用户的系统 WebView 版本。WebView2 在 Windows 上可以通过运行时安装，但老系统如果没有更新，某些 CSS 特性或 Web API 可能不一致。macOS 的 WKWebView 版本则跟着系统走，Edge 模式和 Safari 模式之间的差异，偶尔会让人有一种“做浏览器兼容”的恍惚感。

1.3 一张表格看清技术本质

这只是一个起点级的判断。真正影响选型的，是你在项目生命周期里会遇到的实际问题，比如包体能不能压缩、内存能不能扛住、报错能不能快速定位、安全边界会不会被突破。这些咱们接着说。

2. 实测视角：包体积、内存、启动速度与优化差异

2.1 同一个 Vue 应用，体积差距到底有多大

我用一个很小的 Vue 3 + Vite 项目做过对照测试，页面只有一个列表和一套简单的本地数据操作。Electron 用 electron-builder 打包，Tauri 用自带 CLI 打包，最终结果让我很感慨：Electron 的安装包在 75MB 左右，Tauri 的 MSI 安装包只有 4.2MB。不是说压缩技术有高低，而是 Electron 必须把 Chromium 完整带进场，这部分体积根本无法绕开。

如果你做的是一个内部管理系统，安装包 80MB 可能无人在意，但在面向普通用户的下载场景里，体积直接影响转化率。很多个人开发者的工具类应用选择 Tauri，原因不是因为 Rust 多浪漫，而是用户一看“3MB 就能搞定”，下载意愿会高很多。另外，安装速度也是肉眼可见的差距，Tauri 应用几乎秒装，Electron 应用在机械硬盘上经常会卡在解压阶段。

当然，体积小不代表功能小。Tauri 同样可以调用系统原生能力，只是它走的路径是 Rust 命令和插件系统。只要你的核心逻辑不需要太依赖 Node.js 生态里那些偏门库，Tauri 完全能覆盖日常工作流。

2.2 内存占用：不是“越小越好”，而是看你的用户机器

很多人把“Tauri 省内存”奉为真理，但我觉得要加一个限定条件：在同样的功能密度下，Tauri 确实比 Electron 省。如果你只是开了个空窗口，Electron 可能占用 100 多MB，Tauri 可能只有 20 多MB。但如果你在页面里塞了一个大数据表格、一个 WebSocket 长连接、一堆高频 DOM 更新，渲染进程依然是瓶颈，这部分占用并不会因为换了 Tauri 就消失。

还有一点容易被忽略：Electron 的多进程模型在遇到页面崩溃时更抗打，一个标签页崩了不会带走主进程。Tauri 的渲染进程与 Rust 主进程分离，但整体崩溃恢复能力更依赖系统 WebView 的表现。Windows 上 WebView2 还算可靠，Linux 的 WebKitGTK 偶尔会出现字体渲染或输入法问题，这些是你做跨平台工具时容易看不到的隐性成本。

所以我的建议是：内存敏感就优先 Tauri，但要在测试机上模拟真实用户场景，而不是只看空窗口数据。Electron 用户则可以把精力放在“如何减少渲染进程数量”上，比如避免到处创建隐藏窗口，能复用 BrowserView 或 WebContentsView 就不要新开进程。

2.3 启动速度和热更新体验

冷启动方面，Tauri 通常比 Electron 快。Electron 要初始化浏览器内核，再加载本地资源，启动时间一般多出 0.5 到 1 秒。这个差异在高端机上能感觉到，在机械硬盘和老 CPU 上会被放大。热更新方面，两边都支持开发模式下的即时刷新：Electron 可以用 Vite 的 devServer 加 electron-vite，Tauri 则自带监听。真正有区别的是生产环境的更新机制。

Electron 的更新体系成熟，electron-updater 配合 electron-builder 可以直接处理增量更新、强制更新和签名校验，这也是很多商业应用选它的理由。Tauri 目前也有更新插件，但生态和坑位明显比 Electron 少，尤其是不同平台的签名问题，Windows 的 MSI 和 NSIS 配置差异、macOS 的公证流程，都需要自己踩一遍。如果你的软件要频繁发版给成千上万的用户，更新通道的成熟度一定比包体积更重要。

2.4 两边的优化空间完全不同

Electron 的优化大多围绕“减肥”和“节流”展开，比如压缩 asar 包、清掉不必要的语言文件、开启 GPU 加速、用 lazy load 减少首屏渲染负担。这些操作能把 Electron 从“笨重”变成“可接受”，但不会让它变成“轻量”。Tauri 的优化则围绕 Rust 编译产物和系统 WebView 兼容性，比如裁剪不需要的插件、用 strip 或 opt-level 调整编译优化等级、处理好 sidecar 二进制。问题是，Rust 的编译时间会随着依赖增加而直线上升，一个小项目 clean build 一两分钟算正常，复杂项目可能超过十分钟。你需要提前接受这个节奏，或者用增量编译让它慢慢变得可忍。

3. 2026 年社区高频拷问：IPC、Vue、蓝牙、link.exe 和版本升级

3.1 Tauri 在 Windows 上报错 link.exe not found 到底怎么办

这个问题在 Windows 上特别常见，尤其是刚装好 Rust、第一次跑cargo build或tauri dev的时候。报错信息里出现 link.exe not found，说明 Rust 已经生成了目标代码，但在链接阶段找不到 MSVC 的链接器。你不需要去看什么高级玄学，第一步就是检查 Visual Studio Build Tools 是否安装完整。

打开 Visual Studio Installer，勾选“使用 C++ 的桌面开发”工作负载，里面会包含 MSVC 编译器、Windows SDK 和链接器。装好后重启终端，再运行rustup show看一下默认工具链，通常stable-x86_64-pc-windows-msvc就能正常工作。如果你用的是 GNU 工具链，那报错可能不是 link.exe，而是找不到 x86_64-w64-mingw32-gcc，那就需要通过rustup toolchain install stable-x86_64-pc-windows-gnu或切换工具链来处理。

还有一类更隐蔽的情况：团队电脑装了 Build Tools，但 PATH 环境变量没有更新，尤其是使用 PowerShell 或一些终端插件时，新安装的 SDK 路径不会自动注入。此时可以用系统自带的“Developer PowerShell for VS”，或者在终端里指定编译器路径。我自己的操作习惯是装完 VS Build Tools 后重启一次终端，避免开发环境半新半旧。

3.2 Electron 主进程与渲染进程的通信，到底和 Vue 有没有关系

这个问题我在好几个群里都看到过，其实一句话就能说清：Electron 的 IPC 机制和 Vue 没有关系，Vue 只是运行在渲染进程里的一个前端框架，而 IPC 解决的是主进程和渲染进程之间怎么传数据的问题。你可能看到别人写的代码里既有 Vue 又有 ipcRenderer，就觉得二者是绑定的，其实那只是 Vue 项目经常被用来做 Electron 界面而已。

Electron 的标准通信链路是：主进程通过ipcMain.handle注册一个服务，渲染进程通过ipcRenderer.invoke调用它。为了安全，你通常不会直接在 Vue 组件里调用 ipcRenderer，而是通过 preload 脚本用 contextBridge 暴露一个白名单 API，比如：

// preload.ts import { contextBridge, ipcRenderer } from 'electron' contextBridge.exposeInMainWorld('desktop', { getVersion: () => ipcRenderer.invoke('app:get-version') })

主进程那边：

// main.ts import { ipcMain, app } from 'electron' ipcMain.handle('app:get-version', () => app.getVersion())

Vue 组件里只需要关心“桌面环境给了我一组能力”，至于底层是 IPC 还是别的，根本不关 Vue 的事：

const version = await window.desktop.getVersion()

Tauri 也类似，它在 JS 侧暴露@tauri-apps/api/core的invoke，然后调用 Rust 命令。整个架构对应关系是：Electron 的主进程对应 Tauri 的 Rust 后端，渲染进程都是你的 Web 页面。理解了这个映射关系，你在任何桌面框架之间迁移都会轻松很多。

3.3 Electron 打包 Vue 项目：别让文件协议和路由坑了你

Electron 打包 Vue 项目最常见的坑，是页面用file://协议加载后，Vue Router 的 history 模式失效，或者静态资源找不到。原因很简单：history 模式依赖服务器的路由重写，但在本地文件协议下没有服务器，刷新就变成了 404。解决办法有两条：一是把打包时的base改成相对路径，二是把路由模式改成 hash。Vite 项目里，你需要在vite.config.ts中设置：

base: './'

这样构建出的 index.html 会用相对路径加载 JS 和 CSS，electron-builder 把 dist 目录打进去后，loadFile才能正确加载。如果用的是 webpack 时代的 vue-cli，则对应publicPath: './'和router.createWebHashHistory()。很多新手直接把 web 项目的静态服务器路径搬过来，结果开发环境正常、打包后白屏，大部分都是这个原因。

另外，electron-builder 打包时要注意把前端产物放入files字段，默认情况下它只打包主进程代码，你还需要确认dist和build目录是否包含在 app 目录里。我最常看到的错误是主进程 loadFile 路径写错，文件明明在包里，却因为路径相对当前目录而不是 app 目录而加载失败。建议统一使用path.join(__dirname, '../dist/index.html')这类绝对化写法。

3.4 Electron 访问蓝牙设备到底靠什么

Electron 访问蓝牙主要有两条路：一条是渲染进程里使用 Web Bluetooth API，另一条是主进程里调用 Node.js 原生蓝牙模块。Web Bluetooth API 走了 Chromium 的能力，所以代码和浏览器里差别不大，核心是navigator.bluetooth.requestDevice。但要注意，Electron 里不会自动弹系统蓝牙授权窗口，你需要在主进程里做权限配置，尤其是 macOS 上，还要在 Info.plist 里声明 NSBluetoothAlwaysUsageDescription。

Windows 上走 Web Bluetooth 的体验还算正常，Linux 则需要系统开启 BlueZ，很多精简版 Linux 发行版默认不带，这时浏览器 API 往往直接报错。如果你的项目对蓝牙协议栈的要求比较深，比如要扫描广播包、要维护多连接，或者要操作 GATT 服务的底层句柄，我更推荐在 Electron 主进程里使用 Node.js 原生模块，比如noble的维护分支或@abandonware/noble。因为主进程不受渲染进程沙箱限制，也能直接访问系统蓝牙 API，权限模型更清晰。

Tauri 目前没有统一的 Web Bluetooth 直通方案，通常需要写 Rust 插件去调用系统蓝牙接口，或者使用 community 提供的蓝牙插件。如果你的应用未来主要跑在 Windows 和 macOS 上、且以连接 BLE 设备为核心，这里的时间成本要提前算进去。别只看表面上的“技术很新”，先确认你的功能在对应平台是否有成熟通路。

3.5 Tauri 项目升级版本时，最应该盯住哪些变化

Tauri 的版本迭代比 Electron 明显更快，破坏性变化也更常见。从 Tauri 1.x 升到 2.x 时，很多配置文件和 API 都有变化，比如 capability 文件变成了显式权限声明，插件的引入方式也改了。升级的第一步是同时更新三个东西：Cargo.toml 里的tauri依赖、tauri-build依赖、以及 JavaScript 侧的@tauri-apps/cli和@tauri-apps/api。忘掉任何一个，都可能出现 JS 和 Rust 侧协议不匹配的诡异问题。

更新完依赖后，不要急着运行，先执行一次cargo update，再跑npm run tauri dev。如果报配置解析错误，大概率是旧的tauri.conf.json里的字段失效了。Tauri 2 之后配置更细，权限声明从“默认开”变成了“显式声明”，所以你原来能直接调用的fs、shell、http能力，升级后都可能需要重新授权。社区的 GitHub 模板仓库一般会提供官方样例，建议你在升级前先拉一个最新的 demo 项目，对着 diff 改自己的配置，效率会高很多。

4. 安全模型与跨端边界：选型时的隐性成本

4.1 Electron 的安全边界：contextIsolation 是底线

Electron 被人诟病最多的就是安全配置混乱，因为默认值在历史上并不安全，很多旧教程甚至鼓励直接在渲染进程里开 nodeIntegration。如果你在 2026 年还要新写 Electron 应用，contextIsolation: true、nodeIntegration: false、sandbox: true这三项应该当成默认配置写死在代码里。不要为了省事把 Node.js 直接暴露给页面，尤其当你需要打开远程页面时，渲染进程里的任何 XSS 都可能变成远程代码执行。

preload 脚本是渲染进程和主进程之间的安全桥。你可以在 preload 里用 contextBridge 暴露一组窄接口，而不是把整个 ipcRenderer 对象丢给页面。这样即使页面被注入脚本，攻击者能用的能力也只是你主动暴露的那几个函数。很多开发事故不是 Electron 本身有多漏洞，而是把主进程的权限大面积交给渲染层，一旦上线后出现第三方脚本或用户输入未过滤，后果很难收拾。

另外，Electron 升级频率要跟得上。Chromium 的安全更新会持续修复渲染层漏洞，你不升级，就相当于带着一堆已知 CVE 跑。这个在 To C 场景里尤为重要，到了 2026 年，软件供应链审查越来越严，很多企业采购时都会问一句：你的 Electron 跑在哪个 Chromium 版本上？这一问就能筛掉不少维护不积极的团队。

4.2 Tauri 的权限系统：能力需要显式让渡

Tauri 2 在设计上更偏向“默认最小权限”。你的前端默认不能乱读文件、不能随便执行系统命令、不能访问任意本地服务，开发者必须在 capabilities 文件里声明需要哪些权限。刚开始用会觉得麻烦，但换一个角度看，这是在帮你建立桌面应用的安全习惯。

比如你要在 Tauri 里执行一个外部命令，必须添加 shell 插件的权限，并配置允许执行的命令白名单。只让前端执行某一个 exe，就不要给它shell:allow-spawn这种大而全的权限。能力文件写得好不好，直接决定应用在被攻击时的爆炸半径。Rust 后端本身的记忆安全优势，加上这套显式权限模型，让 Tauri 在安全评审上确实更有卖点。

不过也要留意，系统 WebView 本身会带来新的兼容性风险。Windows 上如果用户机器里 WebView2 Runtime 版本滞后，你的页面可能用到新版 Chromium 特性时表现不一致。macOS 的 WKWebView 对 WebGL、Service Worker 等能力的支持长期以来都在追赶 Chromium，做重交互应用时一定要提前验证。

4.3 鸿蒙移植与跨端现实的温差

2026 年桌面端一个绕不开的话题，是鸿蒙桌面设备的生态适配需求。很多人问“Electron 应用能不能移植到鸿蒙”，从技术上看，这更像是一个改造成本问题，而不是“能不能”的问题。鸿蒙桌面端的 Web 能力容器不是为了跑 Electron 而生，因此你没法直接把 Electron 主进程代码搬过去，更现实的路子是复用你的前端 UI 层，把系统能力层重新实现一遍。

Tauri 和 Electron 在这种场景下处境相似：前端代码可以保留，但文件系统、系统托盘、原生菜单、窗口控制这些能力都得按新平台的 API 重写。你过去为 Electron 封装的 service 层如果足够抽象，这个迁移会顺利很多；如果业务逻辑直接散落在主进程代码里，那无论换到 Tauri 还是鸿蒙，都会是一次伤筋动骨的重构。我的建议是：不管你现在选哪个框架，都要把“系统能力”和“业务逻辑”拆干净，这比纠结框架本身更值钱。

4.4 安全维护成本对比

Electron 的维护成本主要是“跟着上游走”：Chromium 一更新，你就要评估是否需要升级，否则安全债越积越多。Tauri 的维护成本则更多花在“组件兼容”和 Rust 编译链上：Rust 版本更新、WebView 行为变化、插件质量参差，都会让维护者额外花时间。两边没有哪一方能完全躺平，但如果你做的是高价值工具、需要写进招投标文档的安全说明，Tauri 的权限模型论述起来更漂亮；如果你已经有成熟的 Electron 安全加固方案，继续沿用也没有问题。

5. 实战选型：什么样的项目选 Electron，什么样的项目选 Tauri

5.1 选 Electron 的典型项目

我见过最适合 Electron 的项目，不是那些能放进系统托盘的小工具，而是功能密度极高、需要深度集成屏幕采集、原生窗口管理、音视频编解码、硬件外设的大型应用。VS Code 那种复杂的编辑器界面、腾讯会议和飞书这类需要大量原生模块支撑的协作工具，目前用 Electron 依然是稳妥选择。因为 Tauri 的插件生态还没法完全覆盖这些领域的全部底层交互，遇到一个没封装好的能力，你可能就得自己写 Rust，开发周期立刻拉长。

如果你的团队清一色是前端工程师，完全没有 Rust 基础，而业务又要求在三个月内上线，Electron 也几乎是最合理的答案。前端团队写主进程代码没有额外的语言门槛，遇到问题线上能查到海量案例，招聘成本也低。技术“最优解”如果落地成本太高，在业务眼里就是不优解。

5.2 选 Tauri 的典型项目

Tauri 最适合的场景是：小体积、低内存占用的工具类应用，比如 Markdown 编辑器、JSON 查看器、剪贴板管理、API 调试工具、公司内部效率工具。这些应用功能单一，UI 不需要特别炫酷，用户希望“下载快、打开快、不占内存”。我自己的经验是，一旦安装包超过 50MB，很多个人用户就会犹豫；而 3MB 的 Tauri 工具几乎不会成为下载门槛。

另一个很适合 Tauri 的场景，是你已经确定要用 Rust 做后端核心。比如你有一个 Rust 写的图像处理库或数据分析引擎，再用 WebSocket 撑起用户界面，Tauri 天然适合，因为 Rust 后端就在旁边，省掉一层跨语言桥接。类似思路在 GitHub 上能找到不少靠谱的 demo 项目，建议先搜tauri rust desktop demo，挑一个你能读懂的小项目跑一遍，再决定是不是把这个技术栈引入团队。另外，如果你未来有把应用搬上移动端的想法，Tauri 2 的移动端支持也比 Electron 现实得多，Electron 基本停留在桌面。

5.3 从 Electron 迁到 Tauri 的可行路径

很多人会把“迁移”理解为重新写一遍。其实更聪明的做法，是先把界面部分拆成纯 Web 项目，再在两边分别接一层薄薄的桥接层。Electron 用 preload + contextBridge，Tauri 用命令注册和 JS API，前端页面只依赖一组你自定义的window.desktop接口。这样前端代码能保持 80% 以上复用，迁移的时候只需要换环境适配层。

以 IPC 为例，如果你在 Electron 里写了ipcMain.handle('read-config')，迁移到 Tauri 时，就在 Rust 里写一个同名命令#[tauri::command] fn read_config()，前端调用从invoke换成统一封装的函数。你只改封装层，业务层不需要知道底层用的是 Electron 还是 Tauri。这个过程不会轻松，但相比推倒重来已经划算很多。建议把迁移当做一个分期项目来做，先抽出最小可用功能跑通，再逐步替换系统能力，而不是一口气要求所有功能都对等。

5.4 一张可以直接抄的决策清单

这张表不是用来“指定你选谁”，而是帮你把团队现状映射进去。条件越往左偏，Electron 越省心；条件越往右偏，Tauri 的赢面越大。

6. 2026 年的生态观察，以及我给新人的上手建议

6.1 生态热度不是技术优劣

看到 GitHub star 数对比就断定谁更强，是最容易走弯路的判断方式。Electron 的 star 多，是因为它的历史包袱和用户基数大；Tauri 的 star 涨得快，则因为 Rust 社区活跃度高。到了 2026 年，你真正该看的是那些长期维护中的项目都在用什么。DevToys、DBeaver 类的工具越来越多的团队开始切 Tauri，但重量级办公协作软件的主流底座依然是 Electron。这个现状大概率还会维持很久，因为切换成本不只是重写代码，还包括团队能力、插件生态、运维工具链和用户反馈积累。

我自己观察到的趋势是，开源社区里“小而美的桌面工具”越来越倾向于 Tauri，商业公司里“企业级复杂应用”更倾向于 Electron。两者并不冲突，它们服务的是一批不同容忍度的用户。你只要想清楚自己的用户是谁，就不会被社区的情绪带走。

6.2 谁在换，谁在坚持

换到 Tauri 的团队，通常是那种厌倦了 Electron 包体大、内存高的内部工具团队。他们愿意花几周时间填补 Rust 技能空缺，换回更快的启动速度和更低的运行成本。坚持 Electron 的团队，则多半有历史包袱，或者有复杂的原生模块依赖。比如项目里已经封装了一堆 C++ 插件、屏幕采集逻辑、崩溃监控、自动更新签名，这些搬到 Tauri 上都要重新验证，迁移成本高到不值得冒险。

还有一些团队采取混合策略：核心产品继续留在 Electron，新孵化的轻量工具用 Tauri 试水。这样一方面保留成熟的发布管道，另一方面也让团队逐步积攒 Rust 经验。我个人很建议这种“两条腿走路”的做法，它不会让你把所有鸡蛋放在一个篮子里，也能让团队从容地评估新框架。

6.3 新手入门路径该怎么走

如果你完全没有桌面开发经验，想快速做出一个能看的工具，我建议先走 Electron，因为它能让你最快感受到“桌面应用到底是怎么回事”：主进程、渲染进程、打包、签名、自动更新，这些概念基本一晚上就能跑通。不要一开始就追求优化，做出一个能打包发布的小工具，比研究一万篇性能文章都有用。

跑通一个 Electron 项目后，再去玩 Tauri，你会发现很多概念是共通的，但 Tauri 会让你多学一点 Rust 和系统 WebView 的边界。推荐从官方脚手架生成一个默认项目，改一改前端界面，跑一次tauri build，然后试着写一个自定义 Rust 命令，再手动声明权限。一旦你完整走完这个流程，你就已经跨过了 Tauri 入门阶段最大的门槛。

6.4 个人体会

如果让我现在做一个 10 人以内的团队工具，目标用户是 Windows 和 macOS 普通用户，我会直接选 Tauri，因为它能把安装包和内存负担压下来，用户反馈通常也更正面。如果我要做一个功能密度极高、依赖大量系统原生能力的行业软件，我会回到 Electron，因为它的生态和稳定性让我敢对客户承诺交付时间。

我不是在和稀泥。这两条路我都实际走过，知道各自的痛点在哪儿。Electron 的伤害是慢慢积累的，内存越跑越高，包体越来越大，但问题大多看得见、可解决。Tauri 的伤害是一开始集中的，编译失败、权限配置、WebView 差异会让你怀疑人生，可一旦跑顺，日常维护非常省心。框架不会替你成功，但你得知道自己愿意承担哪一边的麻烦，这个选择做对了，后面的路才走得顺。