Tauri 让我们可以用 Web 技术构建桌面应用：Vue 负责界面，Rust 负责调用系统能力。对于一个小工具，这种分工通常已经够用。
但当应用开始拥有复杂启动流程、后台任务、自动更新、文件操作和未保存编辑时，一个问题就会变得越来越重要：
当 WebView 不可用、被隐藏、正在重载，甚至已经崩溃时，应用的关键行为由谁负责？
如果答案仍然是 Vue，桌面应用的可靠性就会被 UI 生命周期绑住。本文讨论一种更稳健的边界：让 Rust Host 拥有应用生命周期，让 Vue WebView 专注于产品呈现和用户交互。
本文中的工程案例来自一个使用 Tauri 2、Rust 和 Vue 3 的真实项目。文中代码是用于解释设计的简化示意，并非项目源码的逐字摘录。
1. 先区分两个生命周期
桌面应用里至少有两个不同的生命周期：
- Native application lifecycle：进程启动、窗口创建、单实例、窗口显示/隐藏、系统托盘、退出、更新安装。
- Renderer lifecycle：WebView 加载、Vue mount、路由初始化、组件卸载、前端状态恢复。
它们有关联，但不能互相替代。WebView reload 不应该等同于应用退出；窗口隐藏也不意味着后台工作应该停止。
一个实用的职责划分是：
| Rust Host 负责 | Vue WebView 负责 |
|---|---|
| 窗口创建、显示、隐藏和退出 | 页面、组件和交互 |
| 单实例与系统菜单/托盘 | 产品级状态展示 |
| 启动截止时间与原生错误恢复 | Bootstrap UI 和可重试操作 |
| 文件、数据库、密钥和进程边界 | 通过 typed IPC 发起受限请求 |
| 关闭前保存屏障 | 汇总编辑器的保存/离开决策 |
| 后台任务的权威状态 | 任务进度的展示和观察 |
关键原则是：需要在 WebView 隐藏或不可用时仍然正确的行为，不应该只由 WebView 驱动。
2. 不要在启动时立即展示主窗口
最简单的实现是在创建窗口后立刻显示它，然后让 Vue 自己加载。但这会产生一个尴尬的中间状态：用户看见了一个空白窗口，却不知道应用是在加载、卡住，还是已经失败。
另一种做法是让主窗口初始隐藏：
- Rust 创建隐藏的主窗口。
- Rust 启动启动截止时间。
- WebView 加载一个轻量的 bootstrap/error shell。
- 前端初始化必要服务，并报告 ready 或 recoverable error。
- Rust 只在应用可用，或已经准备好展示可恢复错误界面时，才显示主窗口。
这并不意味着必须先完成所有后台工作。重点是定义一个明确的“可用”或“可恢复”边界，而不是把 window.show() 放在任意一个 Vue 生命周期钩子里。
OS launches app
|
Rust creates hidden main window
|
start startup deadline
|
WebView loads bootstrap shell
|
initialize required services
|
+---+----------------------+
| |
usable recoverable error
| |
reveal window reveal error UI
项目实践中，启动截止时间由 Rust 在 renderer 初始化前启动。启动超时不是强制杀进程的计时炸弹，而是保证失败能够被明确呈现：原生错误对话框提供 Retry / Quit。Retry 会重新加载现有主 WebView，并启动一个新的 startup generation。
这里有两个值得保留的设计点：
- 启动代次（generation）：重试之后，旧一轮初始化迟到的 ready 信号不能冒充新一轮启动成功。
- 截止时间属于 Host：如果截止时间由 Vue 自己维护，那么 Vue 没有成功启动时，也就没有可靠的机制报告 Vue 启动失败。
3. 一个真实的 Windows WebView2 陷阱：同步 IPC 回调里不要显示窗口
桌面跨平台开发最容易踩的坑之一，是把“API 调用成功”误认为“调用时机正确”。
在 Windows 上，同步 Tauri command 可能运行在 WebView2 的 IPC 回调中。如果在这个同步回调里直接显示此前隐藏的窗口，窗口显示操作可能重新进入消息循环，造成主线程死锁。表现可能是窗口不再响应，甚至启动截止时间对应的错误对话框也无法出现。
危险的结构大致是：
// 示意：不要在同步 IPC callback 中直接做窗口显示
#[tauri::command]
fn renderer_ready(window: tauri::WebviewWindow) {
// 在特定 Windows/WebView2 调用上下文中，
// 直接 show 可能触发消息循环重入问题。
let _ = window.show();
}
更稳妥的原则是：同步 command 只记录或转发状态；窗口变更由异步运行时中的生命周期协调器执行。
// 示意代码：把 UI/窗口副作用移出同步 IPC callback
#[tauri::command]
fn renderer_ready(
state: tauri::State<'_, LifecycleState>,
) -> Result<(), String> {
state.mark_renderer_ready()
}
// 生命周期协调器在异步上下文中观察状态，
// 再执行窗口显示、聚焦等操作。
async fn reveal_when_ready(/* lifecycle state, window handle */) {
// await readiness / recoverable state
// perform window mutation from async runtime
}
这段代码表达的是调用边界，不是可直接复制的完整实现。具体项目还需要处理重复 ready、启动代次、窗口句柄错误和超时竞争。
这类问题值得写进架构文档，因为它不是业务逻辑 bug，而是运行时调用上下文与操作系统消息循环之间的交互问题。
4. 启动错误应该是可恢复状态，而不是白屏
启动流程至少要区分：
starting：必需服务仍在初始化。ready：应用达到可使用状态。recoverable_error：启动失败，但可以展示错误并允许重试或退出。
不要把“页面 mount 成功”当作整个应用 ready。页面可能已经显示，但数据库恢复、偏好设置加载或关键服务初始化还没有完成。
同样，不要让一个可恢复的启动错误变成静默退出。用户需要知道发生了什么，以及下一步能做什么。
如果采用 retry，建议为每次尝试分配一个 generation。ready、error 和 timeout 都必须绑定当前 generation。这样旧 WebView 的迟到回调不会覆盖新一轮启动状态。
5. 关闭窗口不是一个简单的 close() 调用
复杂桌面应用的退出流程，往往比启动流程更难。
例如，用户正在编辑文档，点击关闭窗口。此时可能有多个编辑器拥有未保存草稿，还有已经被接受、正在写入的数据。直接关闭 WebView 可能造成数据丢失。
一个更稳健的 leave barrier 可以按顺序执行：
- Rust 收到 close / quit / updater-install 请求。
- Rust 创建带唯一 ID 的请求，并发送给 Renderer。
- Renderer 汇总各个数据所有者的离开决策。
- 用户可以取消；取消会停止整个 transition。
- 各个 owner 执行保存或保留草稿。
- 已经准入的写操作必须 settle。
- Renderer 只确认它实际处理的那个 request ID。
- Rust 收到批准后才隐藏窗口或继续退出。
Close / Quit request
|
Rust creates request ID
|
Renderer evaluates leave decisions
|
+----+----+
| |
cancel approved
| |
keep UI admitted writes settle
|
acknowledge request
|
Rust hides / quits
为什么需要 request ID？因为关闭请求可能重复发生，Renderer 也可能 reload。一个响应只能完成它所属的请求，不能误完成后来创建的另一个请求。
还要区分“用户取消”和“保存失败”：取消应该停止 transition；保存失败则应该保留编辑器和可见反馈，而不是假装已经保存。
6. WebView 可能失联，Host 必须有自己的判断
如果 Rust 正在等待 Renderer 对关闭请求作出决定，不能无限期等待。
一种做法是让 Renderer 在等待保存或用户决策期间持续发送 heartbeat。Host 只接受与当前 pending request 对应的响应；如果在规定时间内没有 heartbeat，就由原生层给出错误处理。
例如，项目中的策略是每两秒发送一次 heartbeat，十五秒没有 heartbeat 时进入原生错误处理：
- Close：保留窗口，不冒险关闭。
- Quit：显示未保存编辑警告，让用户明确选择保留窗口或继续退出。
这里的重点不是“15 秒是最佳数字”，而是：等待前端响应必须有超时策略，而且超时后的行为要由仍然存活的 Host 决定。
7. 单实例和平台行为也属于 Host
窗口生命周期不止 open 和 close。实际桌面应用还要处理：
- 用户再次启动应用时，已有实例如何聚焦？
- 关闭窗口是退出，还是隐藏到后台？
- macOS 的 Application Menu 和 status item 如何工作？
- Windows 的系统托盘和原生标题栏如何保留？
- Dock / taskbar 进度和通知在 WebView 隐藏时如何继续？
这些行为不应散落在 Vue 组件里。让 Rust Host 统一协调平台能力，再通过稳定的 command/event contract 通知前端，通常更容易维护。
8. 这套设计的代价
Rust Host 管理生命周期并不是免费的：
- 需要维护启动状态机和 request identity。
- IPC contract 必须清晰，不能把所有业务逻辑都塞进 command。
- Host 与 Renderer 之间需要处理超时、重载和迟到消息。
- 平台差异仍然存在，必须在真实 macOS / Windows 环境中验证。
- 不能因为 Rust 更靠近系统，就把 UI 状态和产品呈现也搬进 Rust。
好的边界不是“所有东西都放 Rust”，而是让每种状态由最有能力保证它正确的一层拥有。
结论
Tauri 的优势是让 Web 技术与原生能力协作，而不是让 WebView 成为桌面应用的唯一控制中心。
如果某个行为必须在窗口隐藏、Renderer reload 或 WebView 不可用时继续正确，那么它应该由 Rust Host 拥有或协调。Vue 负责呈现状态、收集用户决策，并通过受限的 typed IPC 请求能力。
这套边界让启动、关闭、恢复、单实例和后台任务有了明确的权威来源，也让桌面应用不再把“页面还活着”误当成“应用还可靠”。
延伸阅读与实际实现
这篇文章中的设计来自我在 Knovum 中的工程实践。Knovum 是一个基于 Tauri 2、Rust 和 Vue 3 的开源桌面应用。
- Desktop foundation：生命周期、安全边界与失败隔离
- System architecture：运行时拓扑与启动恢复
- Architecture：依赖方向与代码所有权
- Knovum source code
欢迎讨论不同 Tauri 应用在启动协调、Renderer 失联和安全退出方面的设计取舍。
