锐评桌面端技术营销：别拿跑分当工程判断

昨天又刷到一篇文章，标题大意是「Electron、Tauri2 该进历史了，Zero-Native 才是未来」。

配图也熟：一张内存占用对比图，一张冷启动柱状图。红的高，蓝的矮，下面接一句加粗结论——Zero-Native 是未来。评论区很快热闹起来，基本都是同一个意思：桌面端终于不用再忍 Electron 了。

我没法跟着叫好。

不是因为图一定有假。Zero-Native 是 Vercel 最近开源的、基于 Zig 的跨端桌面框架，在一些跑分里确实很好看。Tauri2 也确实解决了 Electron 最容易被吐槽的那几个问题：包大、启动慢、内存占用高。

问题是，这篇文章把输入当成了结论。

它没问你的产品到底是什么，没问团队有没有人能长期维护 Rust 或 Zig，没问三个平台的 WebView 差异谁来兜底，崩了怎么收日志，签名公证怎么过，自动更新怎么回滚，也没问五年以后这堆代码谁接。它只比较了两件事：谁的包更小，谁的冷启动更快。

这当然是有用信息。但把一两个跑分指标包装成工程判断，就是另一回事了。

它们到底好在哪

先把话说公道：Tauri2 和 Zero-Native 的方向不是错的。

Tauri2 的模型很干净：Rust 写后端，界面交给系统自带的 WebView，中间用 IPC 打通。Zero-Native 把 Rust 换成 Zig，大方向类似，也是原生后端加系统 WebView。它们的优势很直接：少带一个 Chromium，安装包自然更小，进程模型也更轻。

如果你做的是一个设置面板、一个后台小工具、一个对渲染一致性要求不高的轻量客户端，这个选择很可能很香。用户下载得快，机器负担小，团队也不用为一个简单界面背上完整 Chromium 的成本。

但「小多少」不是一个能脱离场景写进结论的数字。

连 Tauri 官方都只说自己产出的是 "tiny binaries"，不会给一个到处适用的 MB 数。因为它本来就依场景浮动：你打了哪些依赖，目标机器上 WebView 运行时在不在，要不要带补丁，安装器怎么做，每一项都会改写结果。包体积是实打实的优势，但它是一个区间，不是营销文里那个固定的「吊打」。

更关键的是，少带 Chromium 省下来的那笔账，不会凭空消失。它会换一种形式回到你的工程系统里。

「打开一个 WebView」不是难的部分

系统 WebView 的代价，是你不再完整拥有渲染引擎。

Windows 上是 WebView2，macOS 上是 WKWebView，Linux 上常见的是 WebKitGTK。只要产品对渲染一致性、输入法、快捷键、剪贴板、窗口行为、字体渲染有一点要求，差异就会冒出来。某段 CSS 在一个平台没事，另一个平台抖一下；某个快捷键在浏览器里正常，套进桌面壳以后和系统冲突；某个 WebView 运行时版本不对，线上用户就变成了测试矩阵的一部分。

这些问题不是不能解。Tauri2 能做出很好的产品，Zero-Native 也值得观察。但你得承认这里有成本。你省掉的是打包 Chromium 的成本，换来的是跨平台 WebView 差异、运行时依赖和更多端侧环境变量。

而且「打开一个 WebView」本来就不是桌面开发最难的部分。

难的是把产品送到用户电脑上，并且长期送得稳：代码签名、公证、安装器、自动更新、回滚、崩溃收集、托盘、全局快捷键、多窗口、多进程、插件体系。再往后看，还有团队知识结构、上游活跃度、调试工具、构建链稳定性，以及五年后谁还能接得住。

一个方案在某个指标上更优，和它能不能撑住一个长期演进的桌面产品，是两个问题。跑分图只能回答第一个。

我真正服气的两种选择

所以我真正服气的，不是「哪个框架跑分更漂亮」，而是两种很朴素的工程姿势。

第一种是 VSCode。

它就是 Electron，这点从不遮掩。但它没有把 Electron 当成性能问题的万能借口。2024 年，VSCode 官方博客接连发了两篇长文，讲怎么用 Rust 写 WebAssembly 模块，再塞进扩展里跑。对性能敏感的活儿，比如文本处理和语言服务，编成 WASM，扔进 worker，别堵主线程。

这是我认可的 Electron 使用方式：先定位瓶颈，再在现有技术栈里把那一段补结实。不是一慢就归因于框架，更不是换一个壳，把已经踩过的桌面端问题从头再踩一遍。

第二种是 Zed。

Zed 团队写过一篇长文，回忆当年做 Atom 的痛苦：GC 停一下，掉帧；DOM 重排一下，掉帧；帧率稳不住，而且很多原因不在自己手里。那篇文章的目标很明确：用 Rust 和 GPU，把编辑器界面稳定渲染到 120 FPS。

于是他们把编辑器当成游戏来做，自研了 GPUI，一个 Rust 写的、GPU 加速的 UI 框架。宣布 1.0 时，Zed 的逻辑也很直接：如果你想突破借来的抽象层，就要把更多栈握在自己手里。

这条路的账单也摆在台面上。后来他们把整个框架推倒重写，专门写了为什么要大改，又写了 GPUI 2 上线。自己造地基，发现砌歪了，返工的人也只能是自己。没有上游替你扛这一下。

它们其实是同一种人

一个没换框架，一个把整套 UI 框架从零造了出来。摆在一起像是两个极端。

但在我看来，VSCode 和 Zed 是同一种人。

两边都是先撞上具体产品问题，再回头找技术答案。VSCode 知道自己有性能瓶颈，就在 Electron 里用 Rust 和 WASM 把关键路径补结实。Zed 判断现成方案够不到自己要的帧率和控制力，就认下自研框架那笔账，连带后面重写的成本一起认。

这跟「先挑一门正当红的语言，套一个跨端的壳，再拿性能图去喊吊打」，根本不是一回事。前者是问题在前、技术在后；后者是技术在前、理由现编。

工程能力到底是什么

桌面端技术选型里，最容易被低估的能力不是知道哪个框架更新，也不是知道哪个 benchmark 更好看。

是你说得清自己的产品卡在哪儿：启动慢是真的伤用户，还是每周只打开一次？内存占用是核心矛盾，还是稳定更新和插件生态更重要？你的团队愿不愿意为 Rust、Zig、WebView 差异、签名公证、崩溃诊断付账？你今天省下来的包体积，会不会变成明年的维护成本？

Electron 不因为跑分差就自动过时。Tauri2 和 Zero-Native 也不因为跑分好就自动成为答案。它们都是工具，工具的价值要放回产品问题里算。

跑分图谁都看得懂。真正难的，是知道那张图没有告诉你什么。

（完）