STUDIES / FIELD NOTE
用 Electron 与 Tauri 构建真实工作流之后
通过一个翻译工具和一个工资工作区，对两种桌面架构进行实践比较，而不是进行基准测试竞赛
- 桌面应用
- 系统架构
- 产品工程
这篇文章代表当前相对稳定的观点
框架比较常常从安装包体积、内存占用或功能矩阵开始；这些指标很重要，但无法回答六个月后哪一种架构更容易被团队理解与维护
我为两个不同产品分别选择了 Tauri 和 Electron；Aura Translation 是一个小而安静的环境型工具：它驻留在托盘中，响应明确的快捷键或可选剪贴板事件，流式返回翻译，然后退出注意力中心；门店工资助手则是一个运营工作区：它协调员工档案、月度状态、备份、恢复，以及以 Windows 为重点的发布路径
真正有意义的比较不是哪个框架获胜，而是它们分别如何塑造产品逻辑与操作系统之间的边界
产品决定架构
Aura 需要一套窄而明确的界面，以及扎实的原生集成；应用使用 Svelte 构建界面，但它的大部分产品特征来自桌面行为：全局快捷键、剪贴板访问、凭据存储、托盘状态、窗口位置与模型服务流式请求；Tauri 很自然地让这些职责位于 Rust 命令之后，使 Web 界面专注于交互
工资工作区的重心不同；它的复杂度存在于状态转换与操作流程：输入有效性、确认、月结、历史归属、备份和恢复；React 与 Electron 让界面和桌面运行时共享 JavaScript 契约，同时通过 preload 桥限制渲染进程能向宿主请求的能力
两个项目最终都指向同一个关键问题：权威状态应该位于哪里？
Tauri 让原生边界变得明确
在 Aura 中，Rust 核心不只是打包工具；它拥有不应留在 UI 中的能力：模型服务请求、全局快捷键、剪贴板行为、本地历史、配置档案、密钥和窗口编排；Svelte 侧只调用一组刻意保持精简的命令
这种分离会带来有益的约束；增加一项能力时，必须为它命名，定义输入与输出，并决定它是否真的属于前端；对于存储模型密钥、筛选自动复制文本等安全敏感行为，这种摩擦是健康的
代价是每个跨边界功能都有两种实现语境；调试可能往返于 TypeScript、Tauri 权限、Rust 与平台特定行为之间；紧凑的二进制文件并不自动意味着紧凑的开发模型
如果软件的价值依赖安静、原生的体验与严格权限边界，我仍会再次选择这种结构
Electron 优化的是单一语言，而不是单一进程
Electron 减少语言切换，但不应该抹除架构边界；门店工资助手仍然拥有渲染进程、受限的 preload 桥、主进程、共享验证和本地持久化；把这些都视为“只是 JavaScript”，反而会让应用更难保护和测试
真正有价值的是契约复用；备份验证与工作区操作可以由 Web 开发预览和桌面运行时共享；React 面向存储适配器工作，无需知道数据位于开发浏览器还是 Electron 管理的工作区文件
Electron 在这里尤其有效，因为产品本质上是一个拥有桌面能力的复杂界面，而不是带有小界面的原生工具；代价是运行时更大，而且安全模型要求纪律：上下文隔离、窄 preload API、严格 IPC 验证，以及永远不把渲染进程视为可信环境
如果桌面产品的主要复杂度来自丰富 Web 界面和领域模型，而团队又能从 JavaScript 生态中获得杠杆，我仍会选择这种结构
真正重要的比较
| 决策 | Aura Translation | 门店工资助手 |
|---|---|---|
| 产品重心 | 环境型桌面工具 | 运营工作区 |
| 界面 | Svelte 5 | React 19 |
| 宿主权威 | Rust 命令 | Electron 主进程与 preload |
| 核心边界 | Tauri 命令接口 | 存储适配器与 IPC 桥 |
| 正式目标 | macOS 与 Windows 工作流 | Windows 产品目标 |
| 主要风险 | 跨平台原生行为 | 数据完整性与恢复 |
两种架构都不会消除平台工作；Tauri 不会让每项 Rust 能力天然跨平台，Electron 也不会让 Windows 打包天然可信；二者仍然需要真实的安装、权限、升级、恢复和失败路径测试
下次我会先决定什么
选择框架前，我会先写下四件事：
- 产品复杂度位于哪里？ 位于原生集成，还是界面与领域模型？
- 哪个进程拥有权威？ UI 不应悄悄成为密钥、文件或不可逆状态转换的拥有者
- 哪些能力必须离线可用？ “本地优先”需要具体的持久化与恢复模型
- 哪个平台是真正的发布目标？ 构建成功不等于发布可靠
Tauri 与 Electron 都能构建经过认真思考的桌面软件；持久的选择，是让产品最重要的边界变得明显，并让团队有足够能力长期守住这条边界