1.4 适用边界：什么时候别用Tauri

选型评审最怕的是只听优点。本节是全章的落点，也是全册里少数"劝退"篇幅：把 Tauri 不适合的场景摆到台前，给出一张可以直接带进评审会的检查清单。读完本节，你应当能对自己的项目给出"选、不选、有条件选"的三值结论，而不是一句"都能做"。

什么项目应当认真考虑别用

以下场景并非绝对禁区，但每一条都意味着你要为选 Tauri 付显著的额外成本，评审时值得单独论证。

场景一：像素级跨端一致是硬指标。 品牌 UI 规范精确到渲染效果、设计验收按同一像素口径逐端过检的产品，在三个不同内核上做到一致要投入持续的适配成本（第 2 章会看到三端 WebView 的行为差异清单）。此类项目用自带内核的方案更省心。

场景二：重度依赖 Node 生态的原生模块。 核心业务建立在大量 npm 原生扩展（如某些数据库驱动、图像库的 Node 绑定）上，而你没有资源用 Rust 重写时，迁移成本可能远超收益。Tauri 里这些能力要么经命令桥转手，要么找替代插件，都是工程量。

场景三：以 3D 强渲染或游戏循环为主体。 界面本质是 WebGL/WebGPU 重度画布、要求稳定帧率与即时输入响应的产品，WebView 的合成器行为与系统负载耦合，可预期性不如自绘引擎方案。做工具型少量 3D 没问题，做"以 3D 为主体的产品"要三思。

场景四：团队零 Rust 储备且交付窗口极短。 第 5 章会证明常规业务用不到多少 Rust，但"用不到多少"的前提是有时间踩学习的坑。两周内要交付、团队没人写过 Rust、招人无望——这时强行上 Tauri 是给项目埋返工点。

场景五：目标环境是老旧受控终端。 金融柜台机、工业触屏这类系统镜像老旧、无法安装 WebView2 且禁用自动更新的环境，"复用系统组件"的前提不成立，自带内核反而是优势。

什么项目与 Tauri 一拍即合

反过来看，下面这些特征出现得越多，Tauri 的账单越便宜：

• 产品本体是 Web 应用或团队精通 Web 前端，需要一个"能装进用户电脑"的容器；
• 功能以信息展示、表单交互、本地文件处理、调用系统服务为主——笔记、看板、下载器、聊天客户端、监控面板、开发者工具都是典型；
• 团队在意安装包体积、启动速度、内存占用，或分发对象包含大量个人用户；
• 安全合规敏感：数据要留在本地、权限要可审计、不想背整个浏览器的攻击面；
• 有延伸到移动端的可能——2.x 的同构工程让桌面代码平移到 iOS 与 Android。

一张评审会检查清单

把两边收进一张表，逐行打勾。勾的分布倾向哪边，结论就在哪边：

用虚构但真实的"随身笔记"（全册示例应用）过一遍：界面是常规 Web 表单加列表；核心操作是本地文件读写与全文检索（Rust 命令可实现）；个人用户分发，安装包越小越好；笔记数据不离开本机，权限要求可审计；一年内有移动端计划。七行全落在右侧——结论"选 Tauri"就有据可查，而不是凭热度。

图 1-3：选型判断的分流路径

结论怎么写才有用

评审会上的选型结论要能被三个月后的自己检验。建议按"结论、依据、回退条件"三段式写：结论一句话；依据引用本节的清单勾选结果；回退条件写明"若出现什么情况则重新评审"——比如三端适配工作量连续超出预估，或某关键能力在系统 WebView 上无法实现。有回退条件的选型是决策，没有回退条件的选型是站队。

两个折中方案：介于全用与全不用之间

边界场景里还有两条常被忽略的中间路线。路线一：混合共存。 桌面端整体保留 Electron，仅把最重的计算模块拆成独立的 Rust 服务进程供其调用——不必换框架也能享受 Rust 的性能红利；等团队 Rust 能力长起来，再评估全面迁移。路线二：局部试点。 新功能或新版本用 Tauri 起步，老版本继续维护，两条线并行一个迭代周期，用真实的适配工作量替代纸面估算来校准选型。折中方案的价值在于把"全或无"的选型焦虑，转化为可回退的小步验证——工程决策里，能回退的选项永远比孤注一掷的选项值钱。

还有一个容易被忽略的加分场景值得补一笔：内部工具与团队自用软件。这类应用对像素级一致性没有要求、对体积与内存敏感、用户就是你身边的人——三端适配的坑可以现场快速反馈修复，恰是 Tauri 风险最低、上手最快的试验田。不少团队的第一版 Tauri 应用都诞生在内部工具上，跑顺了再推向外部产品，这条路径比自己吓自己省力得多。

一问一答：评审会上最常见的三个追问

追问一：Tauri 不自带内核，用户机器上 WebView 版本老旧怎么办？ 这是真实风险但可控：三平台里只有 Linux 的版本碎片较重，Windows 的 WebView2 随系统自动更新、覆盖率高，macOS 跟随系统版本；功能上按 WebKit 系划基线（2.3 节）后，版本差异主要影响渐进增强项而非核心功能。把"基线功能清单"列进选型依据即可。

追问二：团队没人会 Rust，能不能只写前端？ 大部分功能可以：官方插件覆盖文件、对话框、通知等高频能力，前端不写一行 Rust 也能做出完整应用；只有业务独有逻辑需要芯侧命令，而那部分代码量通常不大。但要诚实预估"通常不大"之外的意外——真遇上要写复杂 Rust 的需求，学习成本就会兑现。

追问三：现在选了 Tauri，会不会两年后被废弃？ 看 维护信号：主版本仍在活跃迭代、官方插件矩阵持续扩充、移动端战略在兑现，生态处于上升期而非衰退期；同时它的核心机制（系统 WebView 加原生后端）并非激进技术，即便生态停滞，已掌握的架构知识也不贬值。风险表述进回退条件，比写进否决票更合理。

本节要点回顾

• 五类慎选场景：像素级一致硬指标、重 Node 原生模块、以强渲染为主体、零 Rust 储备且时间极紧、老旧受控终端；
• 高契合特征：Web 技术栈、轻后端需求、体积内存敏感、安全可审计、有移动端计划；
• 检查清单三值结论：选、不选、有条件选，拒绝"都能做"式和稀泥；
• 回退条件是选型结论的一部分，写下来才能避免沉没成本绑架决策。

第 1 章到此收束：你有了选型的依据。下一章打开装配图纸，把 hello world 背后的三层结构、IPC 传送带与生命周期时序拆到零件级。