时序工作助手最早是用 Electron 写的。功能不算复杂——几个列表、一些定时逻辑、本地存储，没有任何重计算。但它有一个让我每天都能感觉到的问题：这玩意儿太重了。

安装包接近百兆，装完之后占几百兆磁盘，冷启动要等一两秒才出界面。功能上没毛病，可每次点开都先看两秒白屏，用久了心里别扭。于是花了一个周末把它迁到了 Tauri 2。

一、体积和启动，是最直接的动机

Electron 的原理是把整个 Chromium 和 Node.js 运行时打进安装包，所以体积下限就摆在那儿。Tauri 反过来，它不打包浏览器内核，运行时复用系统自带的 WebView2，只把自己的 Rust 后端和前端静态资源塞进去。同一个应用，安装包从近百兆掉到十兆量级，压缩到十分之一左右。

内存占用也跟着降。Electron 应用即使只开一个窗口，常驻内存往往也在两三百兆，因为 Chromium 有一套自己的进程模型。Tauri 只起 WebView 进程和 Rust 主进程，实测下来明显低一截。启动速度更直观：以前点图标之后要等渲染完才敢动，现在基本是即点即开。

对于「一个不太复杂的工具」来说，这个差距是不合理的。功能只值十兆的东西，凭什么要背九十兆的框架。

二、真正花时间的是这三块

如果只看体积，迁移似乎是白赚的。但实际动手之后，成本主要来自下面三件事，跟体积一点关系都没有。

1. 前后端通信全部重写

Electron 里主进程和渲染进程通信靠 ipcMain / ipcRenderer，写法是先注册处理器，再在渲染侧 invoke：

// Electron
ipcMain.handle('read-config', async () => {
  return await readConfigFile()
})

const cfg = await window.api.readConfig()

Tauri 换成了命令宏，把 Rust 函数直接暴露成前端可调用的接口，参数和返回值走序列化：

// Tauri 2
#[tauri::command]
fn read_config() -> Result<Config, String> {
    // ...
}

// 前端
const cfg = await invoke('read_config')

单看一两个接口，改动量不大。但这个项目里散落着几十处调用，而且 Electron 那边习惯把一批操作塞进同一个 handler 里用字符串区分动作，迁过来就必须拆成一个个独立命令。这一步是纯体力活，也最容易漏。

2. 本地存储要换一套方案

原来用的是 electron-store，读写 JSON，API 简单。Tauri 没有等价物，得自己决定数据放哪、怎么序列化、并发写怎么处理。我最后选了在 Rust 侧读写应用数据目录下的 JSON 文件，写操作加一把文件锁，前端只管调命令。

这里有个容易忽略的点：路径获取方式变了。Electron 用 app.getPath('userData')，Tauri 走 app_data_dir()，两者在 Windows 下指向的目录名规则不完全一样。如果老用户已经有一份数据，迁移时要写一段一次性搬运逻辑，否则升级之后数据就「不见了」。

3. 打包和签名流程重来一遍

Electron 那套 electron-builder 配置很厚，但已经调通了。Tauri 用 tauri.conf.json 加 CLI，配置项完全不同，安装包格式、图标规格、更新器的密钥管理都要重新看文档。NSIS 安装包的产物比原来小得多，构建时间也短，但第一次跑通还是花了半天。

三、什么时候我仍然会选 Electron

迁完之后我并没有把 Tauri 当成默认答案。有两种情况我会直接选 Electron：

• 需要 Node 的完整能力。比如应用本身要跑一堆 npm 包、要动态安装依赖、要用某个只在 Node 环境里工作的库。Tauri 的 Rust 侧虽然也能做事，但生态和现成轮子不是一个量级。
• 需要渲染结果绝对一致。Electron 自带内核，用户机器上长什么样是可预期的。Tauri 用系统 WebView，Windows 上是 WebView2，理论上会自动更新，但老系统或精简版系统上仍可能碰到版本差异，CSS 支持度会让你多调试几轮。

另外，Electron 的调试体验更顺手一些，devtools、进程模型、崩溃日志都比较成熟。Tauri 出问题时，报错信息常常停在 Rust 那层，得自己往下挖。

结论

如果目标是一个界面为主的轻量工具，数据在本机、逻辑不复杂，Tauri 2 是更合理的默认选择——省下来的体积和启动时间是用户每天都能感知到的收益，而开发成本主要压在迁移那一次。

反过来，如果应用离不开 Node 生态，或者对渲染一致性有硬要求，别为了省几十兆给自己找麻烦。选框架这件事，应该由功能决定，而不是由体积排行榜决定。