官方插件清单：fs、dialog、shell 与 notification

Tauri 2.x 把系统能力拆成独立插件：用文件系统装插件、用对话框装插件、按需引入。这既是体积控制手段，也是权限体系的一部分。本篇按使用频率介绍最常用的四组官方插件，给出接入步骤与典型用法。

一、文件系统：fs

文件系统插件在 Rust 与前端两侧都能用，是其他插件的基础模板。Cargo 端注册：

fn main() {
    tauri::Builder::default()
        .plugin(tauri_plugin_fs::init())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

前端读写：

import { readTextFile, writeTextFile, appDataDir } from '@tauri-apps/plugin-fs'

const dir = await appDataDir()
await writeTextFile(`${dir}/config.json`, '{"theme":"dark"}')
const text = await readTextFile(`${dir}/config.json`)
console.log(text)

fs 的访问范围由 Capability 的 scope 限制，默认只能访问约定目录，这是 2.x 安全模型的核心，详见「权限模型：Capability 与作用域」。

二、对话框：dialog

对话框插件提供文件选择、消息提示与确认框：

import { open, confirm } from '@tauri-apps/plugin-dialog'

const filePath = await open({
  multiple: false,
  filters: [{ name: '图片', extensions: ['png', 'jpg'] }]
})

const ok = await confirm('确定删除这条记录吗？', { title: '确认', kind: 'warning' })

表中的能力分类清楚展示了边界：

对话框插件的 API 形态以官方文档为准，组件级弹窗仍由前端框架自己实现，插件只处理操作系统原生对话框。

三、Shell

Shell 插件用于打开系统默认程序：用浏览器打开链接、用文件管理器打开目录、唤起外部命令：

fn main() {
    tauri::Builder::default()
        .plugin(tauri_plugin_shell::init())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

import { open } from '@tauri-apps/plugin-shell'

await open('https://tauri.app')
await open('/Users/me/Documents', 'open') // 打开目录，程序名按平台

执行任意外部命令需要额外权限声明，且务必校验输入，避免命令注入风险。同理，打开 URL 前校验协议白名单（只允许 https 等），防止恶意页面利用 shell 协议。

四、通知：notification

通知插件简单直接：

import { sendNotification } from '@tauri-apps/plugin-notification'

if (await isPermissionGranted()) {
  await sendNotification({ title: '同步完成', body: '已更新 128 条记录' })
}

需要先申请权限。macOS 首次会弹系统授权框，Windows 通知中心需要应用注册，各平台行为以系统文档为准。交互式通知（按钮、回复）在部分平台支持，复杂度较高，建议按需扩展。

五、插件引入的通用流程

归纳四个插件的接入共性，只要三步：加 Cargo 依赖并在 Builder 注册、装前端 npm 包、在 Capability 中声明要用的权限。完整清单如下：

版本号请与项目 tauri 主版本匹配，混版会出现 API 不一致。版本兼容的排查可以借助 Claude Code 指南 的辅助分析，依赖配置文件中批量查找版本时 正则 mastery 很顺手。想自己造插件的话，见「自定义插件开发」。

六、插件的组合使用模式

真实应用往往组合四五个插件完成任务。典型组合：

组合时注意权限链：每用到一个 API 就要在 Capability 里声明对应权限，漏一个就报错，权限声明参见「权限模型：Capability 与作用域」。

插件配合窗口管理还能做出更复杂的产品形态，比如同步在托盘菜单里触发、结果用系统通知推送，整套链路把 dialog、shell、notification、updater 全串起来。把每个插件当作积木，产品就是积木的组合方式。

官方插件是 Tauri 生态的地基：每个插件都是现成的最佳实践范例，读它们的源码能学到权限定义、事件封装、前端 API 设计的完整套路。用插件之余偶尔翻一翻源码，你会发现自己写代码的质感在悄悄提升。

插件与「重复造轮子」的边界值得常想：能用官方插件就别自己封装同类功能，社区轮子先搜一圈再动手。Tauri 生态的插件数量还在快速增长，每逢 Tauri 大版本升级时插件也会跟着适配，跟着官方走比自己维护省心得多。

最后提醒插件版本矩阵管理：把每个插件版本号记在依赖表里，升级 Tauri 主版本时同步核对，避免 API 静默变化导致的离奇错误。版本矩阵也是发布检查清单的一部分，值得纳入团队流程。

插件的引入顺序也有讲究：先把核心四件套（文件、对话框、Shell、通知）跑通，再按需加数据库与更新插件，每加一个都同步更新 Capability。一次性引入五六个插件容易出现权限报错无处下手的情况，逐个验证则是线性的排查路径。这套「增量插件化」的节奏建议直接写进新成员的入职文档，能让协作默契快速建立起来，也是降低 Tauri 上手门槛的有效经验。

延伸阅读

• 权限模型：Capability 与作用域——插件能力背后的开关
• 自定义插件开发——官方插件不够用时的下一步
• Rust 入门：阅读插件源码的语法基础