我是做前端的,标准的“科班”出身。最早那会儿,我的世界只有三样东西:HTML、CSS 和 JavaScript。那时候我觉得,只要页面画得漂亮,交互做得丝滑,我就是王者。
后来为了涨薪,我逼着自己学 Node.js,学数据库,摇身一变成了“全栈”。那时候我觉得自己无所不能,从数据库查到接口,再渲染到页面上,一条龙服务,爽!
直到有一天,老板拍着我的肩膀说:“咱们得做个桌面客户
端,既要 Windows 也要 Mac,你研究一下 Electron 搞一搞。”
我当时心想:这有啥难的?不就是把网页包个壳吗?
现在回想起来,那真是我职业生涯里最“天真”的一次误判。
一、 Electron 的甜蜜陷阱
刚开始用 Electron,确实爽。
对于我这种 BS(浏览器/服务器)架构出身的开发者来说,Electron 简直就是天堂。我想用 React 就用 React,想用 Vue 就用 Vue,以前写的那些组件库直接搬过来用。我也确实很快就跑通了一个“Hello World”,甚至觉得这玩意儿比写原生 App 简单多了。
但很快,现实就给了我一记响亮的耳光。
-
体积焦虑与“内存怪兽”
当我把项目打包发给测试的时候,我傻眼了。一个明明没多少功能的聊天软件,打包出来居然有 150MB+!这还不算完,用户一打开,任务管理器里内存直接飙升到 300MB 甚至 500MB。
我在那儿抓耳挠腮地优化,以前在浏览器里,内存泄漏了刷新一下页面就没事了,用户顶多骂一句“这网页真卡”。但在桌面端,用户是花了真金白银买的大内存电脑,你这软件一开占几百兆,而且越用越卡,最后直接崩溃闪退。
那种看着内存曲线像过山车一样往上窜的绝望,做 BS 的人很难体会。为了省那点内存,我开始研究怎么优化 Chromium 进程,怎么配置 Webpack 拆包,头发都掉了一把。 -
并不是所有的 Node.js 都能用
以前做全栈,我觉得 Node.js 是万能的。但在 Electron 里,主进程和渲染进程的分隔让我吃了不少苦头。
我想读个本地文件,以前在服务器端 fs.readFile 就完事了。但在 Electron 里,为了安全,我得搞 ipcMain 和 ipcRenderer 通信。稍微不注意,上下文隔离没做好,XSS 攻击就能让你把用户电脑搞崩。
最要命的是原生模块。我想用个 C++ 写的加密库,结果在 Windows 上编译通过了,一换到 Mac M1 芯片上,直接报错。为了配这个 node-gyp 的编译环境,我装了 Xcode,配了 Python 版本,甚至重装了系统。那一刻我才明白,跨平台不是说你代码写一次就能跑,而是你修一个 Bug,得在三个系统上复现三次。
二、 遇见 Tauri:是救赎还是新的深渊?
被 Electron 折磨得够呛后,我听说了 Tauri。
宣传说它体积小、性能好、用 Rust 写后端。我当时如获至宝,心想终于能摆脱 Electron 这个“重型卡车”了。
- 被 Rust 教做人
兴冲冲地建了个项目,结果第一步就卡住了:我得学 Rust。
对于习惯了 JavaScript 这种动态语言、垃圾回收机制的前端来说,Rust 的所有权机制、生命周期、借用检查器,简直就是天书。
以前写 JS
let data = getData();
process(data);
现在写 Rust:
let data = get_data();
process(data); // 报错:value moved here...
为了写一个文件读写的功能,我得跟编译器搏斗半天。以前觉得简单的逻辑,现在得考虑内存安不安全,线程怎么同步。
- 生态的落差
虽然 Tauri 的前端部分还是用 Web 技术,但涉及到系统底层时,我发现 Rust 的生态虽然质量高,但数量真不如 npm。
我想找个处理 Excel 的库,npm 上一搜一大把,随便挑个下载量高的就能用。到了 Rust 这边,要么文档晦涩难懂,要么功能不全,最后还得自己造轮子。
而且,因为 Tauri 用的是系统自带的 WebView(Windows 上是 WebView2,Mac 上是 WebKit),这就导致了 CSS 兼容性问题。以前有 Chromium 兜底,CSS 写法随心所欲。现在好了,同样的 Flex 布局,在 Windows 和 Mac 上居然渲染得不一样!我又得回过头来写一堆 -webkit- 前缀,甚至写 JS 去判断系统版本做兼容。
三、 客户端开发的“不容易”
兜兜转转这一圈,我最大的感触就是:做客户端,真的太难了。
做 BS 产品,出了 Bug,我发个版,用户刷新一下或者下次访问就更新了。做桌面客户端,出了 Bug,我得让用户下载安装包,还得考虑自动更新机制怎么配,万一更新失败了怎么办?
做 BS 产品,性能瓶颈主要在服务器,前端卡了也就是加载慢点。做桌面客户端,用户会觉得是你软件写得烂,占了他的 CPU,卡了他的鼠标。
难点到底在哪儿?
边界的模糊与打破: 以前我们在浏览器的沙盒里跳舞,现在我们要直接跟操作系统打交道。文件系统、注册表、系统托盘、全局快捷键、原生菜单……每一个点都是一个坑。
对资源的敬畏: 浏览器里我们习惯了“挥霍”内存,但在客户端,每一兆的体积,每一毫秒的启动时间,都是用户体验。
跨平台的割裂感: 你以为你写的是跨平台代码,实际上你是在三个不同的操作系统上走钢丝。Windows 的权限管理、Mac 的沙盒机制、Linux 的各种依赖库缺失,每一个都能让你加班到深夜。
四、 结语
虽然过程很痛苦,掉了很多头发,也骂了很多次娘,但当看到自己写的软件变成一个 .exe 或 .dmg 文件,安装在用户的电脑上,甚至能离线运行、操作硬件的时候,那种成就感也是做网页给不了的。
从 Electron 的“大而全”到 Tauri 的“小而美”,技术总是在迭代。作为前端,我们被迫走出了舒适区,去学习 Rust,去理解操作系统,去处理二进制流。
这很难,但这也许就是前端工程师进阶的必经之路吧。毕竟,不想做客户端的前端,永远只能活在浏览器的那一亩三分地里。




Electron说来说去还是浏览器前端那一套,只不过用个工具给包装了一下,伪桌面软件而已,我就问一句,它能操作当前电脑的内存吗?
真正意义上的桌面软件,还得是C#和Qt这两大传统工具。目前桌面软件主要是工具类软件和工业控制类软件,或者一些有特殊需求、不接受浏览器端的客户。C#优于Qt,但是Qt可用于国产信创场合。
那肯定的,不过有时候得看业务和实际情况
QT 信创不太行. 现在 GUI 信创项目基本让 Electron 跟 Avalonia 垄断了. QT 这东西商业项目涉及到买 License. QT 的开发商所在的芬兰本身也是美国走狗, 而且本来中欧之间积怨就很深, 人家在 License 上卡你一下你就完了. 所以现在信创项目一般都要求必须用开源的, 不涉及商业授权协议的组件. MIT 开源的, LGPL 的都行.
可以尝试pyqt啊?学个python也快,虽然也有很多坑,但不再是那种套界面的了😀
嗯嗯,可以的
你老板本来就选错了
有道理
老板不可能说出:既要 Windows 也要 Mac
可能还想要linux
所以这时候就推荐 Avalonia 了.
讲真现在 2026 年了, 真没那个必要去纠结什么内存不内存的问题了. 200M 能咋地, 500M又能咋地, 现在谁的电脑不是 32GB内存起步啊? 你拼命去节省内存, 客户也不会感激你.
至于因为内存问题就去用 Tauri 就更没必要了. 之所以用 Electron 这种前端技术栈开发 GUI 程序, 其中一个最大的原因就在于开发人员只需要知道前端技术就足够了, 不需要去学习 C/C++/C#/Rust 这些后端语言. 结果 Tarui 逼着开发者去学 Rust. 那请问我既然会 Rust 那我为什么不用 Iced, 或者 QT 这类成熟高效的方案呢?
最后修改于