2021年我拿到一个内部工具需求：需要同时跑在Windows 10和Ubuntu 20.04上，界面要求不高，但要能读取USB扫码枪并弹窗显示。我当时的直觉是Electron，因为团队里没人会C++，而且之前用React写过一个页面，理论上套壳就行。事实也确实如此——两天做出了原型，但真正交付时安装包250MB（未压缩），单进程内存占用稳定在430MB以上，而那个界面的实际渲染内容只是三行文字和一个二维码。用户反馈开机启动后风扇狂转，这个体验比功能本身更让人记忆深刻。
后来我盯上了Tauri，特意拉了一个干净的Ubuntu虚拟机测试打包体积：同样的界面，Rust后端加内置的bundle产物只有8.3MB（deb包）。内存占用实测大概90MB，滚动和动画倒是比Electron流畅不少，因为它直接调系统WebView，不用整一套Chromium。但紧接着问题来了：Ubuntu 20.04默认的WebKitGTK版本是2.36，对CSS backdrop-filter 支持得支离破碎，那杯啤酒色的毛玻璃效果在客户机器上直接变成了灰块。Windows那边则需要确保带WebView2 Runtime——好吧，Win11内置了，可我的目标用户里还有不少Win10 LTSC，只能追加一个静默安装脚本。Bugs不止一处：扫码枪键盘楔式输入在Tauri的webview里偶发丢首字母，最后还得写一个全局快捷键绕路，这在Electron下从没发生过。
纠结了两个月，我试着用原生写了一个内部版本——注意，只是一个大体的原型。在Windows上用C++的Win32 API从头写了大概700行，加一个静态链接的libcurl，打包完是1.2MB的exe，双击即用，内存才12MB。但要在Linux上复现就得由另一个同事维护GTK版本，两套UI逻辑完全不可复用，改一个界面细节得同步改两处代码。而原生的最大福利不是性能，而是对系统行为拥有绝对控制权：扫码枪输入丢失问题？我直接改用Windows的Raw Input API在消息循环里接收，100%可靠。然而要处理HiDPI自适配和DPI scaling时，我花了一天读文档加反复测试，在win10 150%缩放下的模糊问题最终用manifest声明PerMonitorV2才解决。这个成本，以我们团队一个月的工作负荷根本扛不住长期迭代。
最后我想说，现在很多文章只拿打包体积和内存数值来神化Tauri、踩Electron，但等你真的做生产级软件时，会发现在所有Web技术方案里Electron反而是最不可能被底层平台差异拖累的层：因为Chromium不依赖系统组件，你不必去研究多少个Linux发行版内置的webkit会崩。而Tauri和原生之间也并非优劣关系，它们是三种完全不同维度的成本模型：Electron付的是硬件资源，买的是用户环境一致性；Tauri付的是适配运气，买的是低资源占用和更小的攻击面；原生付的是工程学代价，买的是一旦做好便极度稳定、可以十几年不变的“遗产级产品”。一个业余爱好者推荐的方案未必能支撑商业场景，企业做工具软件更要先盘算目标机器上有没有不可触的运行时依赖——我现在会先问客户：你的PC允许装驱动/运行时么？不允许，那就只能回到原生，或者直接放弃你用Web技术写的那个好看界面。
桌面开发不是选秀赛，没有一个工具是全世界通用的银弹。你以为你在选框架，其实你在选未来那些夜里等你在用户现场解决问题的机会成本。Electron堆出来的臃肿很诚实，Tauri的精简背后藏着一套不稳定生态，原生则用陡峭的学习曲线惩罚每一个只想速度、不想长期投入的项目。如果我再从头做那个扫码工具，大概会稳妥地同时写三个prototype：Electron的留作最终兜底，Tauri的当性能实验，原生的则来验证关键IO路径是否可控——然后根据预算和老板脾气，砍掉其中两个，记住你砍掉标准是你维护项目的长期能力，而不是开会时那一页PPT上写着的体积对比表。
