为什么我选择了 Tauri 而不是 Electron 来实现这个桌面工具？

在 AuraShell 的技术选型阶段，第一个也是最重要的问题并不是“用什么前端框架”，而是 “用什么承载整个桌面引擎”。作为一款直接嵌入 Windows 桌面环境、需要与系统深度交互、还不能拖累性能的工具，底层框架的选择几乎决定了项目的基因。

我们面前有两个主要选项：Electron 和 Tauri。很多人会下意识地认为 Electron 是 Web 技术栈写桌面的唯一选择，毕竟 VS Code、Figma、Discord 都在用。但当我们仔细审视一个“桌面美化工具”的实际需求时，答案变得异常清晰——我们选择了 Tauri (Rust 驱动)。

下面我从三个决定性的角度来展开：极致性能、系统级调用能力和包体积。

一、极致性能：桌面工具不能是“内存吸血鬼”

Electron 应用本质上是在自带的一个 Chromium 浏览器里运行网页。这意味着，无论你的应用功能多简单，启动时都会加载一整个浏览器内核，包括 V8 引擎、渲染进程、GPU 进程、网络服务……即便你只是想在桌面上显示一个天气小组件，Electron 也会吃掉数百 MB 的内存。

这在一个“桌面增强工具”的场景下是不可接受的。我们的用户已经开了 VS Code、Chrome、Figma，可能还跑着 Docker 和 WSL。AuraShell 作为常驻后台的应用，必须轻若无物。理想状态下，它应该像系统托盘图标一样安静，只在需要时唤起 WebView2 渲染界面。

Tauri 从根本上改变了资源模型：

• 没有自带浏览器内核：Tauri 使用操作系统原生的 WebView（Windows 上为 WebView2，即 Edge 内核）。用户电脑上已经存在这个引擎，我们只是复用它。这意味着零额外运行时。
• 后端逻辑用 Rust 编译为原生二进制：Rust 代码直接编译为机器码，不需要解释器或虚拟机。文件监控、壁纸层注入、窗口管理这些任务全部由 Rust 处理，运行在原生性能水平。
• 进程模型极度精简：一个 Tauri 应用通常只有两个进程——主进程和 WebView 渲染进程。而 Electron 则可能启动多个辅助进程。

结果是什么？AuraShell 在空闲状态下内存占用仅有 15MB 左右，播放动态壁纸时保持在 50MB 以内。而一个仅展示静态壁纸的 Electron 壳就可能占用 200MB+。这种量级的差异不是优化能够弥补的，这是架构层面的优势。

我们做过一个简单的对比测试：创建一个空的 Electron 应用和一个空的 Tauri 应用，打开后什么都不做。Electron 的空壳内存约 120MB，Tauri 约 5MB。放上一个简单的 HTML 页面，前者直奔 200MB，后者平稳在 15MB。在桌面工具领域，这种差距意味着“用户会卸载你”和“用户忘了你在运行”之间的区别。

二、系统级调用：原生交互不是“模拟”出来的

AuraShell 不是普通的窗口应用。它要实现的功能包括：

• 将壁纸层嵌入桌面图标下方（WorkerW 窗口）
• 监控文件系统变化以自动整理图标
• 创建透明、穿透点击、置底的组件窗口
• 与系统托盘、任务栏、桌面图标层无缝共存

这些操作需要直接调用 Win32 API，有些甚至涉及未公开的系统窗口句柄。在 Electron 里，你可以通过 Node.js 的 ffi-napi 或 node-win32-api 来调用系统 API，但这本质上是一种“外交手段”：你在一个浏览器进程里开了一个隧道去访问外部世界，每一次调用都要跨越 JS 引擎、Node 绑定、C++ 扩展层，性能和可靠性都打了折扣。

而且有些细粒度的操作，Electron 的 Node 层根本做不到。比如我们需要在壁纸窗口上精确控制窗口样式（WS_EX_LAYERED、WS_EX_TRANSPARENT），需要监听特定文件夹的 ReadDirectoryChangesW，需要和桌面图标窗口 SysListView32 进行消息通信。对于 Electron，你要么写一个 C++ 原生模块弥补，要么放弃。

Tauri 提供了“原生优先”的能力：

• 后端代码直接是 Rust，可以零开销调用任何 Win32 API。你不需要额外的绑定层，不需要 node-gyp 重新编译地狱。
• Tauri 的 API 体系天然支持窗口控制、文件系统访问、系统托盘、全局快捷键等，而这些在 Electron 里往往需要额外的包或原生模块。
• 更关键的是，Tauri 允许你在 Rust 侧处理复杂的系统逻辑，仅将最终结果以 JSON 格式传递给前端 WebView。这意味着前端代码永远是轻量的 UI 描述，真正的“重活”全在 Rust 里完成。

举个例子：AuraShell 的桌面图标整理功能需要实时监控多个文件夹，当文件增删改时自动触发重排。在 Rust 里，我们直接用 notify crate 监听文件系统事件，高效且零延迟。如果换成 Electron，你需要通过 Node 的 fs.watch，它底层依赖 libuv 的事件循环，效率和可靠性都不在一个级别。

系统级调用不是“能跑就行”，而是要求原生级响应速度和稳定性。Tauri 的 Rust 后端让我们感觉像是在写一个纯正的 Windows 程序，而前端只是挂载在上面的 UI 壳。这种架构天然适合我们这种桌面引擎。

三、极致包体积：安装包不是下载一个浏览器

我们经常看到这样的场景：用户想试用一个桌面小工具，下载一看 200MB，安装完 500MB，瞬间劝退。Electron 应用打包时会把整个 Chromium 运行时塞进去，这让最基础的“Hello World”应用也轻松超过 100MB。

对于 AuraShell 这样的工具，包体积直接关系到传播和转化率。我们计划的推广路径包括在 V2EX、GitHub、社交平台上发布，用户的第一印象往往来自下载速度和解压后的大小。如果安装包太大，很多人甚至不会等到安装完成就取消了。

Tauri 在包体积上的优势是压倒性的：

• Tauri 应用分发的是编译后的二进制文件，体积通常只有几 MB。我们的核心程序预计 5MB 以内。
• 它依赖操作系统自带的 WebView2，无需携带浏览器运行时。Windows 10 1803+ 已内置或可自动安装 WebView2，用户无感。
• 资源文件、前端 UI 文件（HTML/JS/CSS）会打包进二进制，但经过压缩后非常小。

对比一下：一个典型的 Electron 应用（如 Wallpaper Engine 的 UI 工具）安装包轻松数百 MB。而我们用 Tauri 构建的整个桌面引擎，可能比一张高清壁纸还小。这种反差本身就是一种技术叙事：“你正在下载的，不是一个浏览器套壳，而是一个纯粹的原生程序。”

另外，包体积小还意味着更新成本低。我们可以频繁发布补丁而不会让用户每次下载几十 MB 的增量包。对于内测阶段快速迭代尤为关键。

选择 Tauri，其实是选择一种哲学

Electron 并非没有价值，它让无数 Web 开发者能快速构建跨平台桌面应用，它的生态和成熟度无可比拟。但它的设计初衷是“把 Web 应用搬到桌面”，基因里带着浏览器的重装部队。

AuraShell 的定位则完全不同。我们不是一个移植来的 Web 应用，而是一个从 Windows 桌面内生出来的工具。它需要像水一样渗透到系统的每一个角落，需要极致的轻量和原生感。Tauri 给了我们这种可能性：用最优秀的系统级语言（Rust）处理底层逻辑，用最灵活的 UI 技术（Web 前端）呈现界面，两者之间通过最精简的 IPC 桥接。

如果用一句话总结：Electron 让你拥有一把瑞士军刀，而 Tauri 让你直接动用操作系统本身的手术刀。 对于一个桌面引擎而言，我们需要手术刀。

目前 AuraShell 正在首批 300 名内测招募中。如果你想体验一个由 Rust 驱动、几 MB 大小、却能彻底改变桌面的工具，欢迎来信申请。

📧 申请内测：liuxinye660@gmail.com
🌐 官网：https://aurashell.dev

下一篇文章我们将深入技术细节：如何用 Rust 调用 Win32 API 将自定义壁纸层嵌入桌面图标下方。Stay tuned.