Rust+系统WebView替代Electron，应用内存从524MB压到8MB

一个开发者用 Rust 把聊天应用的内存占用从几百兆压到个位数，这事儿听起来像个段子，但确实发生了。

tw93 受不了 Slack 一打开就吞掉几百兆内存。他在 2022 年开始动手，用 Rust 和 Tauri 重新包装了这些网页应用。核心思路很简单：扔掉 Electron 里打包的完整 Chrome 引擎，换成操作系统自带的 WebView 组件。结果怎么样？Slack 的 Pake 版本只占 8MB 内存，而原版要 524MB。Discord 和 ChatGPT 也分别从 265MB 和 260MB 降到了 9MB 左右。四年过去，他的仓库在 GitHub 上已经拿到超过 5.1 万颗星，还提供了多个常用工具的现成打包版本。推动这件事的，不是什么大团队，只是一个人对现状的厌烦。

普通用户打开多个协作工具和 AI 应用时，电脑不再那么容易被拖慢，风扇也不用狂转了。以前每个应用都像自带一套重型引擎，现在改成轻量调用系统已有的组件。资源省下来了，多任务切换也更流畅。这就好比高铁检票，没必要给每个车次都建一个完整的售票大厅，直接用站台已有的闸机和显示系统就行。

从技术角度看，Electron 的问题在于它把 Chromium 的渲染、JS 执行和网络栈全打包进应用进程里。哪怕只是个静态页面，也要为每个应用启动独立的浏览器实例。Tauri 则把前端渲染交给系统 WebView，后端用 Rust 写轻量逻辑。理论上这能把基线内存占用压低一个数量级。当然，网页内容本身的复杂度还是会影响到最终数字。

我以前做过一个用 Electron 打包的简单内部工具。启动后内存轻松突破 300MB，在内存吃紧的机器上用户反馈特别明显。后来做 profiling 才发现，大部分开销都来自重复初始化的浏览器内核部分。看到 tw93 的方案，我不禁想，如果当时早点转向系统 WebView 路线，体验应该会好很多。

Electron 把整个浏览器引擎塞进每个应用，这笔重复开销其实可以省掉。

为什么 Electron 应用总在偷偷消耗资源？

Electron 的出现，本意是让 Web 开发者能快速做出跨平台桌面程序。用 HTML、CSS、JavaScript 写界面，再用 Node.js 调用本地能力。听起来很美，但实际打包后，每个应用都携带了一个完整的 Chromium 副本。

你可以这么理解：相当于每个 App 都自己带了一台完整的浏览器，而不是借用系统已经装好的那个。结果就是启动慢、内存高、磁盘占用大。尤其是在同时开 Slack、Discord、浏览器、编辑器的时候，资源竞争就显现出来了。

从技术架构看，Electron 应用通常有两个主要进程。主进程负责窗口管理和本地 API 调用，渲染进程则是完整的浏览器实例，负责页面渲染和 JS 执行。即使页面再简单，V8 引擎和 Blink 渲染引擎也得加载起来。每个应用独立一份，系统没办法有效共享这些开销。

有一次团队项目，用户在 Windows 上同时跑两个 Electron 应用，内存就直奔 1GB 去了。后来我们换了思路，内存问题才缓解。说实话，当时我完全没想到系统 WebView 能提供这么大的改进空间。

当然，Electron 也不是一无是处。对于需要深度本地集成的复杂应用，它提供的 API 更丰富，调试也更方便。但边界条件就在这里显现了——每个 Electron 应用都要自己处理 Chromium 的安全更新。一个应用有漏洞，得等开发者发新版才能修补。而系统 WebView 跟随操作系统更新，补丁能更快覆盖。

Pake 具体换了什么，让体积和内存都下来了？

Pake 的做法是不动网页内容，只换包装方式。用 Tauri 框架做壳子，Rust 写原生部分，渲染交给操作系统提供的 WebView。

这样打包出来的应用，体积通常在 5 到 10MB 之间。相比 Electron 动辄上百 MB 的安装包，差别相当明显。内存占用也因为没有了重复的完整浏览器引擎而大幅降低。

打个比方，以前是给每个网页配一台独立浏览器，现在改成用家里已经有的电视机来显示。电视机是系统提供的，大家共用，维护也由系统负责。

对于开发者来说，Tauri 允许通过配置文件控制窗口行为、图标、快捷键、是否隐藏标题栏等，甚至支持沉浸式窗口和拖放自定义。这些小功能让打包出来的应用看起来更像原生程序。构建过程也相对简单，一次配置后，后续修改网页内容再打包会快很多。理论上，Rust 的编译特性还能让最终二进制更小、更安全。

不过实际效果还是得看具体系统和网页内容。Windows 上的 WebView2 基于 Chromium，内存节省可能不如 macOS 上的 WKWebView 明显。不同场景下数据会有波动。我以前判断说系统 WebView 方案只适合简单展示类应用，复杂交互还是得 Electron。后来看到有人用 Pake 打包了带实时协作的工具，交互体验也没掉太多，才发现自己之前想得太绝对了。

应用	原 Electron 内存	Pake 版本内存
Slack	524 MB	8 MB
Discord	265 MB	9 MB
ChatGPT	260 MB	9 MB

这些数字在自己的电脑上基本能复现，前提是网页内容复杂度类似。内存对比数据是在特定测试环境下得到的，实际使用中如果网页加载了大量脚本或媒体资源，占用还是会比静态页面高一些。

自己动手打包一个网页应用，需要哪些步骤？

想把常用网页变成轻量桌面程序，流程其实不复杂，但第一次需要准备环境。

先确认系统有基础编译工具，需要 Rust 工具链和 Node.js 运行时。这些东西安装后会占用几 GB 磁盘，第一次下载依赖也很花时间。原因在于 Pake 底层靠 Tauri 框架，Rust 负责把原生逻辑编译成高效二进制，Node 则处理网页资源的打包和注入。你可以把这步看成做饭前先把锅碗和食材备齐，后面重复操作就顺手了。

环境就绪后，全局装一下命令行工具：

npm install -g pake-cli

装好就能在终端直接输入 pake 命令调用打包流程。

然后执行核心命令：

pake https://example.com --name MyApp --width 1200 --height 800 --icon ./icon.png --hide-titlebar

输入目标网页地址，加上应用名称和可选参数，比如窗口宽高、自定义图标、是否隐藏标题栏。Pake 会自动拉取网页内容、合并配置、调用底层构建工具生成平台对应的可执行文件。整个过程就像把网页“编译”成独立程序。第一次构建因为要编译 Rust 部分会慢一些，后续改动再跑就快很多。

构建结束后，在当前目录或输出文件夹里能找到对应系统的应用文件。macOS 是 .app 包，Windows 是 .exe，Linux 是 AppImage 或 deb。双击打开就能像原生程序一样使用，任务栏或 Dock 里也会出现图标。

如果不想折腾本地环境，仓库的 Releases 页面已经放好了 Slack、Discord、ChatGPT、Gemini 等常用工具的预编译版本，直接下载对应平台的安装包就行。哪里容易出错？网络不稳导致依赖拉取失败，或者 macOS 上首次打开被系统拦截，需要去安全设置里允许。Pake 还支持通过 GitHub Actions 在云端完成整个构建，不用本地装任何工具链，对只想快速试用的人特别方便。

跑完后打开应用，内存占用通常能稳定在个位数 MB 级别，同时开多个也不会让系统资源监控曲线剧烈波动。自定义参数用得好，还能做出无标题栏、支持拖拽的沉浸式窗口，体验比普通浏览器标签页更专注。

如果你也受够了电脑被一堆网页套壳应用拖慢，不妨去仓库 Releases 下载几个现成版本先试试。或者自己用命令行把常用网页打包一下，释放出来的内存可以留给本地模型推理或者浏览器多开标签。

很多时候，技术方案的简化不是靠堆功能，而是有人愿意把重复的依赖砍掉，让系统各司其职。现在打开你的任务管理器看看，哪个应用最该被重新包装一下？💬