用 Web 前端加 Rust 开发桌面应用，只说明了 Tauri 的部分用途。它的架构还有一项重要安排：由操作系统的 WebView（网页视图）渲染界面，让原生代码负责高权限操作，并明确规定两者之间允许哪些调用、各自能访问哪些资源。[1][2][3][10] 到了 2026 年，这仍是评估 Tauri 的重点。Tauri 已经能创建窗口；团队选择体积更小、更贴近宿主系统的应用外壳时，还要准备承担相应的权限设计与管理工作。

官方项目页面列出了各部分的分工。Tauri 应用可以使用任何能编译成 HTML、JavaScript 与 CSS 的前端框架，后端逻辑则可以用 Rust、Swift 或 Kotlin 编写。[1] 仓库 README 与架构说明进一步介绍：tao 管理跨平台窗口，WRY 对接系统 WebView，Tauri core 统合运行时、配置、命令、资源与打包流程。[1][2][10] 这些组件共同遵循一项设计选择：沿用操作系统的渲染器，尽量精简应用自身需要携带的代码。

配图说明：题图采用 Tauri 官方 1.0 发布页上的联合创始人 Daniel Thompson-Yvetot 肖像。[9] 与通用的编程配图相比，项目参与者的照片更贴合本文所讨论的设计取舍：桌面应用中，哪些代码可以信任，哪些调用需要检查。

小体积来自对系统 WebView 的使用

项目首页列出三项优势：安全基础、更小体积、前端选择灵活。[1] 体积最受关注，README 则交代了它所依赖的条件。Tauri 借助 WRY 的抽象层，在 macOS 与 iOS 上调用 WKWebView，在 Windows 上调用 WebView2；Linux 对应 WebKitGTK，Android 对应 Android System WebView。[2] 应用使用操作系统管理的渲染器，省去了随包附带的 Chromium。

这种设计减少了应用需要打包的内容。Tauri 应用主要交付自身代码、资源、衔接各部分的原生代码，以及明确开放的 API。[1][2] 架构说明还介绍，Tauri 的 codegen 会在构建阶段嵌入资源、计算哈希并压缩资源。这也体现了项目的设计取向：精简应用的交付内容，减轻捆绑浏览器带来的体积负担。[10]

对于希望开发桌面应用、又希望减轻浏览器打包负担的团队，这项设计很有吸引力。相应的代价是，渲染行为取决于各平台的 WebView，跨平台的一致性受到限制。[2] 同一套应用运行在几种系统渲染器上，团队选择 Tauri 时，也要接受并处理这些差异。

Rust 之外，IPC 决定前端如何访问系统

Tauri 的安全文档明确区分了两类代码：核心应用或插件中的代码拥有完整的系统访问能力，WebView 中的代码则只能经由进程间通信（IPC）访问系统资源。[3] Rust 有助于提高核心代码的安全性，IPC 则决定前端代码能够调用哪些原生功能。两者承担着不同的安全职责。[3][10]

README 还介绍了一项细节：Tauri 使用 WebView 原生协议（native WebView protocol）直接向 WebView 交付内容，省去 localhost HTTP 服务器这一环节。[2] 架构说明随后解释了前端怎样调用后端：@tauri-apps/api 为前端设置 JavaScript 调用入口，再经由 WebView 与宿主之间的消息传递层请求后端操作。[10] 前端调用原生功能时，需要经过这条受权限约束的通道，提出明确命名的请求。

这套设计能否发挥作用，取决于团队如何编写命令。若工程师用 invoke 随意调用原生代码，前端与原生代码之间的权限隔离就会被削弱。若逐条界定命令权限，并严格限定每条命令接受的数据，Tauri 的设计便能更充分地发挥作用。[3][4]

用 permissions 与 capabilities 明确授权范围

在 v2 中，这些权限安排有了具体的配置方式。permissions 文档将 permission（权限定义）解释为对命令权限的显式描述，并允许搭配 allow 与 deny scopes，分别规定允许与拒绝访问的范围。[5] capability（能力配置）参考页说明，可以按精确名称或 glob 模式匹配窗口或 WebView，再为它们分配权限。应用的不同部分因此可以有各自的访问范围。[6]

runtime authority 文档说明了运行时的检查过程。WebView 发起 Tauri 命令调用时，runtime authority（运行时授权检查组件）会核验 origin（调用来源）是否获准、是否匹配某个 capability，并在执行前按需要向请求注入相关 scope。来源未经许可的调用会在执行前被拒绝。[4] 这套权限管理方式细化到了窗口、WebView 和命令类别，比全局统一的允许列表更为细致。

对工程师来说，这些分工比“更安全的 Electron 替代品”更具体：permissions 规定命令可以做什么，[5] capabilities 规定这些权限对哪些窗口或 WebView 生效，[6] runtime authority 负责在执行时检查并拦截未获授权的调用。[4] capability 文件直接决定应用的访问权限，应当纳入架构审查。

插件越多，越要逐项审查权限

Tauri 2.0 稳定版发布博文介绍，新的访问控制系统已经覆盖核心 API，应用开发者与插件开发者都可以使用同一套 permissions、scopes 与 capabilities。[7] 博文也解释了将更多功能移入插件的原因：降低贡献门槛，让核心部分保持稳定，同时把变化较快的功能拆分为相对独立的模块。[7] InfoWorld 在 2024 年 8 月的报道中概括，Tauri 2.0 将 1.x 的大部分核心功能移入插件，使这些功能能够独立迭代。[8]

拆分之后，应用团队仍需承担安全审查责任。每接入一个插件，团队都要确认它开放了哪些命令、默认授予哪些权限、scope 如何限定，以及前端能够调用哪些功能。[5][6][7][8] Tauri 文档说明，插件开发者可以预先定义权限，应用开发者可以复用、扩展或缩减这些权限集。[5][7] 这种灵活性需要细致的审查才能发挥价值：团队应像审阅 API 网关策略或移动端 entitlements（应用授权声明）一样，逐项核对 capability 文件。

适用团队与使用中的限制

Tauri 适合熟悉 Web 界面开发、希望应用更贴近桌面或移动系统的团队，前提是团队愿意缩小高权限操作的范围，并逐项写明约束。[1][3] 如果包体大小、启动体验或与宿主操作系统的集成比渲染行为完全一致更重要，Tauri 就尤其值得考虑。[1][2]

使用中的限制主要有三项。首先，各平台 WebView 存在差异，前端依赖浏览器在少见情况下的行为时，差异会更加明显。[2] 其次，Linux 上的打包与运行仍依赖系统中的 WebKitGTK。[2] 最后，权限管理要求团队具备平台工程意识：默认授权过宽、命令设计含混，都会很快削弱 Tauri 的安全优势；框架本身谨慎的安全设计也难以弥补这些疏漏。[3][4][5][6]

在 2026 年评估 Tauri，把 HTML 与 Rust 写进同一个应用只是起点。更值得关注的是各部分怎样配合：系统 WebView 渲染界面，原生核心执行高权限操作，IPC 负责两者之间的通信，capability 文件规定访问权限。[2][3][4][5][6][7][10] 愿意按这种方式组织应用的团队，能从 Tauri 中得到很大价值。即使最初只为缩小二进制文件而来，团队最终仍要认真设计和维护调用权限。

来源

1. Tauri，《What is Tauri?》：框架总览，安全基础、小体积与灵活性，以及依托系统 WebView 控制包体大小的理由。
2. Tauri README：各平台的 WebView、native WebView protocol、支持平台及项目概况。
3. Tauri Security 总览：core / plugins 与 webview 代码之间的信任边界，以及 IPC 层如何约束权限跨越。
4. Tauri，《Runtime Authority》：命令 origin 校验、capability 匹配、scope 注入，以及在执行前直接拒绝未授权调用。
5. Tauri，《Permissions》：显式命令权限、allow / deny scopes、permission sets，以及插件与应用层的权限组合方式。
6. Tauri，《Capability》参考页：向窗口或 WebView 分配权限、glob 匹配方式，以及用于隔离 IPC 访问的 capability 对象模型。
7. Tauri，《Tauri 2.0 Stable Release》：统一的 permissions / scopes / capabilities 模型、插件化迁移，以及 v2 外部安全审计摘要。
8. Paul Krill，《Tauri 2.0 moves core functionality to plugins》。InfoWorld：从外部概括插件迁移及其独立迭代收益。
9. Tauri，《Tauri 1.0 Release》：本文题图所用 Daniel Thompson-Yvetot 官方肖像来源页。
10. Tauri ARCHITECTURE.md：Tauri core crates、编译期配置、资源 / codegen 责任，以及 JavaScript 到后端的命令桥接。