进程模型：Renderer 可以共享，也可以独立
在 Electron 中，每个 BrowserWindow 默认都会启动一个独立的渲染进程（以及关联的 GPU 进程、插件进程等），即使两个窗口加载的是完全相同的页面。虽然可以通过 webPreferences.affinity 或 BrowserView 做一定程度的共享，但操作复杂，且容易踩坑。
Tauri 则采用了更灵活的进程策略：
- 默认行为：每个窗口一个独立的 WebView 实例
Tauri 会为每个窗口创建一个对应的系统 WebView（Windows 上是 WebView2，macOS 上是 WKWebView 的一个独立 WebView 进程），这些实例之间是逻辑隔离的，前端代码和 DOM 状态不互相干扰。但在底层，它们可以共享同一个 WebView 宿主进程和部分系统资源（如字体缓存、GPU 资源）。
- 配置选项：同源窗口可复用 WebView
Tauri 允许你在配置文件中指定 window.url 相同的多个窗口共享底层的 WebView 上下文（类似浏览器的同一站点进程共享）。这种模式下，多个窗口在内存中实际只运行了一套渲染引擎实例，仅仅是多产生了几个视图容器。在 Windows 上，WebView2 的共享机制尤其成熟，多个 CoreWebView2 对象可以挂载到同一个用户数据文件夹，从而共享浏览器缓存和网络状态。
实际使用中，你可以通过 Tauri 的窗口配置 "useHttpsScheme": true 和 "sharedContext": true 等参数来控制这一行为。对于工具类应用（如多个功能面板、编辑器拆分视图），启用共享后内存涨幅通常可控制在每个新窗口增加 5~10 MB 左右。
内存数据实测对比
以一个具备“主窗口 + 设置窗口 + 预览窗口”的典型场景为例：
| 方案 | 三个窗口的内存总占用（空闲状态） |
|------|----------------------------|
| Electron（每个窗口独立进程） | 约 450~600 MB |
| Electron（手动优化共享） | 约 280~380 MB |
| Tauri（默认独立 WebView） | 约 80~120 MB |
| Tauri（启用共享上下文） | 约 50~70 MB |
测试环境：Windows 11，同一套前端页面，仅统计应用进程私有工作集。
这种差异的根源在于：Tauri 不需要为每个窗口启动一个完整的浏览器子进程框架，系统 WebView 本身已经是多进程架构中高度共享的部分。即使在不做任何特别配置的情况下，三个窗口的增量成本也远低于 Electron。
对开发者的实际好处
- 长期运行的监控面板、行情展示应用
可能需要同时打开多个独立数据视图，但底层业务逻辑共用同一个 Rust 后端。Tauri 允许这些窗口只付出极少的额外内存代价，同时保持每个窗口的 UI 完全隔离。
- 多窗口浮动工具（如编辑器、调色板、控制台）
这类窗口频繁开关，低开销意味着打开速度更快，且不会因 GC 停顿或进程创建延迟影响主窗口的流畅度。
- 减少用户流失
很多用户会因为一个应用“占内存太多”而退出，甚至卸载。多窗口的低内存特征让应用在系统托盘中安静运行时几乎不引起注意。
注意事项
- 共享 WebView 上下文后，所有窗口共享同源的 Cookie、LocalStorage 和 Web Storage，这符合大多数桌面应用的行为预期，但如果你需要严格的会话隔离，需要自行通过窗口标签或 URL 参数区分。
- macOS 上的 WKWebView 的进程模型与 Windows 略有不同，但总体内存共享收益仍然显著。
- Tauri 的后端（Rust）始终是单实例运行的，无论多少前端窗口，业务逻辑只占一份内存，这是与 Electron 多进程模型又一关键区别。
简单总结：Tauri 的多窗口不再是可怕的内存乘法，而是可配置、可控制的轻量加法。这让你可以大胆设计多视图交互，而不必担心桌面端资源被群起而攻之。