企业官网建设流程全解析

我接过不少“把网页包成桌面程序”的需求，每次都会被同一个问题卡住：到底选CEF、Electron还是Tauri？

先说说这段时间我为什么又把这三个框架翻出来。前阵子接了个工业上位机项目，团队里前端是写React的，桌面端是写C#的，后端还掺了一堆Python脚本。需求听起来不复杂：左边一个实时曲线图，右边一个参数配置面板，下面还要挂个串口数据监听的日志窗口。可要做到对外发布、自动更新、不同机器上不出幺蛾子，选型就成了绕不过去的第一道坎。

市面上聊这三个框架的文章不少，但多数停留在“A包体大、B性能差、C有安全风险”这种层面，看完还是不知道怎么选。这篇文章我直接按“从需求反推框架”的逻辑写，把串口通信、HTML转EXE、系统菜单、H.264视频、ARM64这些实际需求全摊开，逐个框架过一遍，最后给出一套可以直接抄作业的选型判断方法。无论你团队是纯前端、纯.NET还是Rust爱好者，都应该能从中找到符合自己处境的答案。

1. 这三个框架不是同类工具，先把定位捋清楚

很多人一上来就纠结性能、内存、包体积，其实方向错了。CEF、Electron、Tauri这三者根本不在同一个抽象层级上，拿它们直接对比参数意义不大，甚至会误导选型。先搞清楚它们各自是什么，后面所有讨论才有立足点。

CEF全称Chromium Embedded Framework，本质是一个“嵌入式浏览器内核SDK”。它不给你提供任何应用壳子，也不管你主程序用什么语言写。你拿C++或C#（通过CefSharp）把它嵌入到自己的桌面程序里，在你的窗口内渲染网页，网页里的JavaScript可以和你宿主语言互相调用。适合的场景是“我本来就有原生桌面应用，只想在里面嵌个网页模块”，比如工业上位机、医疗设备控制台、炒股软件，都是CEF的典型地盘。

Electron则是“完整的桌面应用运行时”。它自带了主进程（Node.js）和渲染进程（Chromium），并提供了一套IPC机制让两边通信。你要做的只是写一个main.js入口，然后把HTML/CSS/JS塞进去，打包出来就是一个独立桌面应用。VS Code、Slack、Discord都是这么干的。它的核心优势是“纯前端团队也能做桌面应用”，而且生态非常完备，菜单、托盘、通知、自动更新基本开箱即用。

Tauri的思路完全不同。它不走“打包一个浏览器进去”的路线，而是调用操作系统自带的WebView（Windows上是WebView2、macOS上是WKWebView、Linux上是WebKitGTK），后端用Rust写，前端照样是HTML/CSS/JS。因为不塞Chromium，包体积可以压到几MB，内存占用也比Electron低不少。代价是你要会一点Rust，而且跨系统表现受“系统WebView”差异影响，不是每个API在所有平台上都一样。

为了后面讨论方便，我先把三者的基础差异列成一张表：

一句话概括：CEF适合“已有原生应用，要补网页能力”；Electron适合“前端团队快速做全功能桌面应用”；Tauri适合“在意体积和内存，愿意学Rust，不想捆绑完整Chromium”。

理解了这层差异，再看下面那些具体需求，就不会被带偏了。

2. 底层架构的差异，决定你的项目天花板在哪里

2.1 渲染内核：自带的Chromium和系统WebView差在哪

Electron和CEF都内置Chromium，这意味着你的HTML/CSS/JS能力只取决于内置Chromium版本，跟用户机器上装了什么浏览器、什么系统设置完全无关。这个特性在两种情况下特别值钱：一是你的UI要用比较新的Web技术（比如Canvas渲染、WebGL、WebCodecs），二是你要保证所有用户无论在哪台机器上，渲染结果都一模一样。

我自己实际对比过：Electron在写复杂Canvas动画时，帧率比Tauri稳定得多。原因不复杂，Tauri在Windows上用的WebView2虽然是Edge内核，但某些嵌入式场景会受系统策略影响——比如企业域环境把WebView2升级到最新版，或者公司组策略禁用了某些GPU加速项，你的页面就在毫不知情的情况下变了样子。这种事情在CEF和Electron里基本不会发生，因为内核是程序自带、完全可控的。

Tauri在Linux上尤其要注意。Linux发行版的WebKitGTK版本参差不齐，你可能在Ubuntu 22.04上测试一切正常，但客户的CentOS 7上页面布局直接崩了。虽然Tauri官方对部分Linux发行版有兼容性说明，但实际踩坑的概率远高于Windows平台。如果你的用户群体包含大量Linux工作站，选Tauri之前一定要做好WebView版本兼容测试。

2.2 进程模型：崩溃隔离和权限边界不是一个量级

Electron和CEF都继承了Chromium的多进程架构：主进程负责调度、窗口生命周期和系统资源，渲染进程负责页面渲染，每一个标签页或窗口独立成进程。好处是某个页面崩溃不会拖垮整个应用，坏处是内存占用肉眼可见地增加。空窗口状态下，Electron的内存占用大概在150MB到250MB，CEF因为不包含Node.js运行时，会稍微低一点，但也在100MB上下。

Tauri的进程模型简单很多：一个Rust主进程管理窗口和应用生命周期，每个WebView窗口是一个独立系统进程，但进程数量和资源开销都明显小。刚启动一个空白Tauri应用，内存占用可以压在20MB到50MB。对于配置不高的工业电脑、嵌入式工控机来说，这个差距非常现实。我有一次在老的i3工控机上同时跑Electron版工具和Tauri版工具，体感差距就像开机一样大。

但多进程架构有个问题常被忽略：进程多了，管理和通信复杂度也跟着涨。Electron的主进程和渲染进程之间必须走IPC，而且渲染进程默认没有Node环境（出于安全考虑）。你在HTML里直接require一个Node模块，报错“require is not defined”的时刻，每个Electron新手都经历过。Tauri因为只有一个Rust主进程，前端调用后端能力必须走tauri::command命令通道，这套机制设计得挺干净，但凡是复杂点的结构化数据传递，通信代码会写到你手麻。CEF那边的JavaScript与宿主双向调用则要自己约定桥接协议，最自由也最容易写乱。

2.3 技术栈的选择，其实是在选团队的学习成本下限

技术选型不能只看框架本身，还得看团队里谁在干活。

Electron对纯前端团队最友好。你只需要会JavaScript，入口文件几百行就能跑起来，npm生态里什么都有，遇到问题Google一下也全是答案。缺点是“解决问题的能力”被限制在Node.js和前端圈子里，真要碰到需要调用Windows原生API、写驱动级代码的需求，会非常被动。

CEF团队一般是有C++或C#功底的人主导，前端只负责写页面。宿主程序是你的主战场，网页只是一个“模块”。C#配合CefSharp时，“用网页做界面、用C#做逻辑”的组织方式非常顺手，但前提是团队里要有人能扛住原生这边的坑——比如CEF版本升级导致API变更、多进程生命周期管理、C++和C#资源释放这些。

Tauri的隐形成本是Rust。不等同于“会一点语言基础”，你要理解所有权、生命周期、异步运行时，才能在遇到问题时不抓瞎。我有同事从Java转过来，看了一周的Rust书才敢动代码。但这门语言认证很实在：一旦你跨过门槛，Tauri后端性能和稳定性都会给你惊喜，很多Electron里需要用C++写原生模块解决的性能问题，Rust里直接写就行。

这三条路线没有绝对好坏，完全取决于你的团队结构和长期技术路线。前端强势的团队选Electron，原生技术栈深厚的团队选CEF，喜欢挑战技术债少的团队选Tauri，都是合理的。

3. 高频硬需求逐个拆解，对照你自己的业务看

3.1 串口、USB和硬件通信：这三个框架谁更顺手

串口通信是硬件类桌面软件绕不开的需求，工业设备、医疗器械、物联网调试工具几乎天天要用。这个需求在三个框架里的解法差异非常大，选错框架后续会相当难受。

Electron这边走的是Node生态，直接npm install serialport就可以用。但要注意，serialport这类包含原生模块的包，必须和Electron的Node版本配套。常见的坑是：你用npm install装好serialport，运行main.js时报NODE_MODULE_VERSION不匹配。解决办法是加装electron-rebuild，在安装完依赖后跑一遍重建脚本：

npm install --save-dev electron-rebuild ./node_modules/.bin/electron-rebuild

还有个环节容易被新人忽略：渲染进程默认不开Node环境，你没法直接在网页里require('serialport')。我有段时间图省事，在渲染进程里开了nodeIntegration，结果被团队安全审计打回，后来改成“串口读写全放在主进程，渲染进程通过IPC通信”，既解决了安全问题，也顺手把界面卡顿问题解决了。因为串口数据回调和UI渲染不在一个线程里，UI复杂度升高后不会互相干扰。

CEF因为宿主语言是C++或C#，串口能力直接调用原生SerialPort类就行，不依赖任何框架。CefSharp里用C#写一个串口读取类，然后注册成JavaScript对象，页面里的JS直接调用C#方法拿数据，属于比较标准且可靠的方案。但要注意所有阻塞性操作不能放在UI线程里，否则CEF的消息循环会被卡住，页面会白屏或者直接无响应。

Tauri在串口这边走Rust crate路线，serialport这个crate非常成熟，配合tauri::command暴露给前端调用。Rust的强类型和错误处理机制在处理二进制协议时顺手得一塌糊涂，解析串口数据帧时尤其有优势。但如果你对Rust的async生态不熟，建议先用标准线程+通道（std::sync::mpsc）把串口读取和命令分发解耦，别一上来就上tokio，容易把自己绕晕。

选型结论：Electron适合“快速实现，团队以前端为主”的硬件应用；CEF适合“宿主本来就用C#/C++，串口逻辑复杂到需要深度控制”的重型上位机；Tauri适合“要严格控制内存和体积，原生逻辑用Rust写也不排斥”的新项目。

3.2 把HTML网页转成EXE：三种路线的具体姿势

“使用Electron将html网页转为exe”是个搜索热度很高的需求，其实本质就是“套壳”。这个场景低到一行代码就能上手，高到要考虑生产环境的自动更新、代码签名和资源保护，差距巨大。

Electron套壳最省事的工具是nativefier，一条命令就能把任意网页变成桌面应用：

npx nativefier https://example.com

但这类工具做出来的应用只适合走后门演示，真要做产品级应用，还是得老老实实写Electron项目，入口加载你打包后的前端dist目录，配合electron-builder出安装包。这里有个很重要的经验：本地开发用http://localhost:5173，生产环境用file://加载dist目录，二者路径语义不一样，不少项目在这个地方翻车。

Tauri同样可以做网页套壳，官方提供了create-tauri-app模板，前端目录放你要构建的静态文件，配置tauri.conf.json的beforeBuildCommand为你的前端构建命令，加载路径指向前端构建产物。因为Tauri不需要在客户端装Node，也没有“Node环境泄漏”的安全风险，打包出来的单文件体积优势非常明显。代价是你要先安装Rust工具链，光这一点就劝退了很多纯前端团队。

CEF做套壳就费劲一些。C#的CefSharp可以用NuGet安装，然后新写一个WinForms或WPF窗口，在Load事件里初始化CefSettings，加载你本地的index.html。整个过程对熟悉WinForms的人来说不复杂，但对只会写网页的团队来说，从一个index.html到一个能发布的EXE，中间要跨越的WinForms/WPF知识落差并不小。

我的建议是：如果你的最终目标只是“把网页包成exe分发给少量用户”，Electron的nativefier和electron-builder是最快路径；如果目标是产品级的长期维护项目，Tauri在体积和维护成本上反而会越走越轻；CEF则适合那个“网页只是附属模块，主程序是原生应用”的场景。

3.3 系统菜单、托盘和多窗口：桌面应用的“原生感”从哪来

很多从网页转过来的开发者会低估“桌面原生感”的体验成本。网页里你可以随便做一个顶栏菜单，但桌面上用户期望的是系统级菜单栏、托盘图标、右键菜单这些原生组件。这三个框架在这里的成熟度完全不同。

Electron的Menu、Tray、Notification、dialog模块都是正统的官方API，开发体验和文档都是三个框架里最成熟的。托盘图标配合右键菜单实现“最小化到托盘”“开机自启”“退出”这类功能，基本一个小时能全部写完。而且Electron对macOS的Dock菜单、Windows的跳转列表这些平台特性也有封装好的API，只是细节上还需要按系统做条件判断。

CEF需要走“宿主程序自己写系统菜单和托盘”的路线。WinForms里建一个NotifyIcon控件，ContextMenuStrip设置好右键菜单，再把菜单点击事件对接到CEF窗口里。这套逻辑对老WinForms开发者来说轻车熟路，但前端程序员接手就很吃力——菜单的选中状态、禁用逻辑、快捷键冲突这些问题都要在原生代码里维护，没法用HTML状态树那一套去管理。

Tauri在v2里对Menu和Tray的官方支持明显加强，但写法偏向Rust配置式，你需要先定义Menu结构，再绑定事件处理器，字段比较繁琐。如果只是做“打开窗口”“退出应用”这类固定菜单还好，一旦要做复杂的动态菜单（比如根据串口开关状态禁用/启用某项），需要把菜单状态通过Rust侧重新构建，再调用窗口刷新，比Electron的操作繁琐不少。

“原生感”这种东西用户嘴上不说，但每次右键弹出一个网页风格菜单，或者点击关闭按钮发现程序没退出、只在托盘藏起来了，用户心里都会咯噔一下。选型时一定要把这个维度纳入考虑，尤其做面向普通消费者工具时，Electron的优势会明显放大。

3.4 视频播放和H.264编解码：一个隐藏的超级大坑

搜索热词里出现了“cef arm64 h.264”，这个关键词背后是一个很容易被忽略的技术债：Chromium内核里是否内置了带专利的H.264/H.265解码器。

CEF默认发行版的ffmpeg是去专利的，不包含H.264/H.265编译选项。这意味着你在CEF里播放mp4/hls/m3u8这类视频，可能直接黑屏或者报错，但换成WebM格式又正常了。网上搜“CEF h264”能找到一堆讨论，结论基本一致：要么自己用Chrome源码编译时带上proprietary_codecs，要么引入系统的ffmpeg做解封装再给渲染器。自己编译CEF是个工程量大、且需要维护特定版本配置的活儿，日常项目里真不建议为了一个视频解码功能去蹚这趟浑水。

Electron这边则自带带专利解码器的ffmpeg，H.264视频播放基本是开箱即用。我测过在Electron 28+里直接放HLS流，起播速度和播放稳定性都在可接受范围，监控类项目、视频回放类项目用Electron能省掉大量编解码基础工作。但要注意，Electron内置ffmpeg不一定支持“最新编码格式”，比如新发布的视频编码格式就可能会不支持，这时需要替换ffmpeg.dll或用系统播放器方案兜底。

Tauri走系统WebView路线，Windows上WebView2使用的是系统级Edge内核，视频解码能力直接继承自浏览器，主流视频协议都没问题。Linux上WebKitGTK播放H.264要看系统是否安装了GStreamer的编解码插件（gstreamer-plugins-bad、gstreamer-plugins-ugly等），没有装就播放不了。所以如果你用Tauri做视频类应用，一定要把“系统依赖”写进部署文档，否则换一台精简系统的机器又要排查半天。

这个坑对视频监控、会议、培训类工具影响尤其大。我的建议是：如果你不确定产品以后会不会引入视频能力，Electron是这个维度最省心的选择；CEF必须提前确认解码许可和编译配置；Tauri则在Windows上没问题，Linux部署要提前做系统依赖检查。

3.5 ARM64与Windows on ARM：硬件换代前的免疫针

“cef arm64 h.264”里还带出了ARM64这个关键词。Windows on ARM的笔记本、平板、云电脑这两年明显变多，高通骁龙X系列机型也陆续上市，桌面应用如果不提前做架构适配，后面会被用户追着骂。

Electron从v12左右开始提供官方arm64构建，安装包下载的时候选arm64即可。但里面的原生模块（比如serialport）需要手工重建arm64目标，electron-rebuild命令行里指定--arch=arm64就行。坑点在于，很多第三方模块的预编译二进制没有提供arm64版本，装完报错找不到文件，这时候只能本地编译，很考验机器上的构建环境。

CEF有官方Windows ARM64构建版本，但CefSharp对ARM64的支持以前不太理想，新版本已经跟上，但如果你用CEF的C++接口写宿主，或者要搭配OpenGL/DirectX渲染，在ARM设备上的驱动兼容性问题会多不少。真要在ARM设备上摊开CEF，建议先拿目标设备跑一个demo，确认渲染、输入、硬件加速都正常再往下走。

Tauri在这块优势是天然的，因为你的渲染端是系统WebView2，宿主Rust程序针对ARM64目标编译tupchen即可。Rust对跨平台目标架构支持一直很稳，cargo build --target aarch64-pc-windows-msvc就能出包。这也是Tauri在“多架构分发”这个维度上领先另外两个框架的地方。

如果你预判产品生命周期会有三到五年，而现在正处于新建项目选型期，把“是否要提前适配ARM64”写入决策清单绝对不亏。

4. 工程化角度：体积、性能、打包、更新，每一样都决定项目生死

4.1 包体积和内存占用：用户的C盘和内存条不会说谎

包体积是这个话题下最直观的差异。一个最简单的Electron应用，打包后安装包就要100MB以上，装上之后目录还要更大。CEF也不遑多让，发行目录里光cef.pak、v8_context_snapshot.bin这些内部文件就几十MB，加上必要的DLL，总量轻松破百。Tauri这边可以做到“安装包几MB、安装后十几MB”的级别，对比非常震撼。

但这并不意味着Tauri一定是“最优”。包体小的代价是运行时要依赖系统WebView组件，Windows 10/11一般自带WebView2，但Windows Server、某些精简版系统里不一定装，你还得在部署脚本里加一步“安装WebView2 Runtime”的逻辑。换句话说，Tauri把“应用体积”换成了“运行时依赖”，不是白赚的。

内存占用差异同样不能只看绝对值。Electron空窗口跑150MB，Tauri空窗口跑30MB，看起来差距很大，但如果你在Electron里开一个复杂页面（比如数据大屏），Tauri因为统一用系统WebView也不一定占得少。关键在于：Electron的内存是“每个窗口独立进程”的，开多窗口内存翻倍更明显；Tauri每个窗口虽然是独立进程，但WebView的底层内存管理更轻，多窗口场景下优势更大。

根据我实测过的项目数据，一个典型的业务工具（带表格、图表、多个Tab页面）在Electron里跑起来大概400-600MB，Tauri大概100-150MB。对于普通办公电脑来说，这个差异用户感知不到；但在工控机、老服务器、低配虚拟机里做开发工具，Electron这个大块头就可能成为被拒绝部署的理由。

4.2 构建、打包和自动更新：从开发环境到用户桌面的最后一公里

Electron的构建链已经非常工业化。electron-builder和electron-forge都能很好地处理安装包、签名、多平台产物、自动更新。配合GitHub Actions或本地流水线，打包发布几乎是全自动化的。尤其自动更新这块，electron-updater支持Windows的NSIS目标、macOS的dmg和zip更新，踩坑最多的是代码签名：Windows上不签名，SmartScreen会拦截你的安装包，用户在“更多信息-仍要运行”里点两次才会放行，这个体验会流失不少用户。

CEF的构建和发布则是典型的原生应用流程。宿主程序按C#/C++标准流程编译，再把CEF运行时DLL按目录结构一起打包。自动更新要么用你已有的更新云服务，要么自己实现“下载新版本-校验-替换DLL-重启”这套逻辑。没有官方现成的更新器，工作量会比Electron大不少。

Tauri的构建体系跟Rust紧密结合，cargo build后会有tauri build命令，能生成msi/nsis安装包。Tauri自身也带更新器（updater模块），但配置项和签名机制比Electron复杂一些，需要生成Rust的签名密钥和公钥，部署前建议在文档里写清楚。遇到过小伙伴第一次配更新器，忘记把公钥放到tauri.conf.json里，发版后用户端一直报“签名校验失败”，排查半天才发现是签名配置没到位。

这里有个通用经验：不管选哪个框架，“签名”一定要纳入发布流程，越早越好。申请代码签名证书、把签名工具加到流水线、在测试环境验证签名效果，这些Debug版本就要做起，别等正式发布才临时抱佛脚。

4.3 安全与依赖链：被忽视的内容安全风险

很多团队选型时完全忽略“依赖供应链安全”，直到出了供应链漏洞才追悔莫及。Electron的依赖面是整个Node.js生态，npm install随随便便拉上百个依赖包，任何一个包被污染，你的桌面应用就会成为攻击入口。常见的缓解手段是锁定依赖版本、启用npm audit、定期升级Electron版本，但本质上“依赖越多，暴露面越大”。

Tauri的依赖主要通过Cargo拉取Rust crate，供应链风险比npm小一些，但同样存在。好在Rust生态里crate的发布和审计更严格，Cargo.lock锁定依赖后，风险相对可控。CEF的供应链风险更集中——它本身就绑定Chromium这个大依赖，Chromium一爆漏洞，CEF通常要跟进发布补丁版本，你的宿主程序是否及时升级，决定了你暴露在已知漏洞下的窗口期。

当然还有一层桌面应用特有的风险：如果你在渲染进程里开了Node集成（nodeIntegration: true），那任何XSS漏洞都能直接变成远程代码执行漏洞。Electron官方安全实践文档强调的contextIsolation、禁用nodeIntegration、设置CSP，我有一次在开发环境开了nodeIntegration图方便，结果页面里一个第三方图表库被注入了恶意脚本，差点出事。从那以后我对“渲染进程绝不能碰Node能力”这条规矩执行得非常严格。这一点在三套框架里的特性级别完全不同：Electron是默认有Node能力的，要靠开发者主动关闭；CEF里渲染进程本来就没Node环境，风险天然小；Tauri后端是Rust，前端也不能直接调系统能力，中间要过命令白名单。安全性设计上Tauri和CEF先天就有优势。

5. 选型决策：不要追框架热度，按业务场景反推才是正解

5.1 四类典型场景的选型建议

第一类：工业自动化、医疗仪器、实验室设备的上位机软件。这类项目的特点是有大量硬件通信（串口、USB、网络、数据采集卡）需求，UI逻辑相对固定，部署环境可能是老电脑，对稳定性和长期维护有极高要求。首选CEF或者Tauri。CEF适合“老工程师习惯C#/C++开发、不想改变现有架构”的团队；Tauri则适合“新项目，愿意引入Rust做后端逻辑”的团队。Electron也能做，但如果你要牵涉驱动级硬件、工业总线协议，纯粹依赖Node生态会比较吃力，到后面你还是得写C++插件，那就绕回CEF路线去了。

第二类：面向大众用户的效率工具、文档工具、开发者工具。这类项目需要大量系统API集成（托盘、菜单、通知、快捷键、登录服务），迭代节奏非常快，团队以前端技术为主。Electron的生态和成熟度是无敌的，VS Code、Notion、Obsidian都验证过这条路。追求更小体积、更省资源的团队可以考虑Tauri，但要做好用户机器上WebView版本不确定的心理准备。

第三类：简单的网页套壳、内部小工具、数据展示面板。如果需求就是“把这个HTML打包成一个exe/安装包发给同事用”，Electron配nativefier最快；如果内部有IT能力帮忙维护Rust环境，Tauri也能做到类似效果还更轻。CEF在这里偏重了，除非你本来就有原生WinForms项目在维护，顺手嵌一个CEF反而顺手。

第四类：移动端同步适配、跨端一体的新项目。Tauri有Tauri Mobile，Electron官方不支持移动端，CEF完全没必要在移动端用。如果产品路线是“桌面+移动端一套前端代码”，Tauri是目前三个框架里唯一能覆盖两条战线的路线，但移动端生态还不算特别成熟，要用的话务必先做POC验证多端表现。

5.2 一张决策速查表，直接对着自己的情况勾选

如果你看完这表还是纠结，那也别急着敲定。我的实操经验是：拿2-3天时间，每个框架写一个最小demo，把你项目里最担心的1-2个核心功能（比如串口读取、视频播放、托盘菜单、自动更新）分别跑一遍，用真实数据和手感来投票。纸上对比做得再多，都不如亲手跑一次来得准。

6. 最后再分享几条踩坑记录

这三个框架我都在真实项目里跑通过，分开说说我个人的体会。

在CEF项目里，我印象最深的是C#宿主动态加载本地网页资源时，相对路径特别容易出错。CEF的本地资源加载默认走file://，页面里的JS和CSS经常因为BaseUrl不一致找不到，后来统一改成用自定义Scheme处理（比如改成cef://）才彻底根治。这个坑在文档里很难提前学到，只能现场踩。

Electron项目里我最想提醒的是：别在渲染进程里贪图方便开nodeIntegration。宁可多写几行IPC，也要保持主进程和渲染进程的权限边界清晰。这个习惯养成了，就算以后遇到XSS也不会直接导致设备被人控制。尤其是拿Electron做的内部工具，很多团队会因为“反正是内网用的”而放松，但内网工具被攻击的例子并不少。

Tauri项目里，Rust后端的内存管理和线程安全从一开始就要按规范写。我有段时间图快，用一个全局可变状态存串口数据缓存，结果多窗口并发读写时出现奇怪的数据错乱，查了三天才发现是共享状态没加锁。后来全部改成通过tauri's state管理或者用Mutex包裹，才算干净。Rust的编译器已经很严格了，但并发模型的设计还是得靠人自己上心。

最后再说个选型外的话题：无论选了哪个框架，发布前的真机兼容性测试都不能省。Electron要把不同Windows版本、不同分辨率、是否装过VC++运行库都测一遍；CEF要确认目标机器显卡驱动不会导致GPU进程崩溃；Tauri要确认WebView2 Runtime、系统更新策略不会影响你的页面表现。软件写出来不难，能让它在五花八门的用户环境里都不出问题，才是桌面开发真正考验人的地方。