接入前端框架：Vue、React 与 Svelte

接入前端框架：Vue、React 与 Svelte

Tauri 的前端可以是任何能产出静态页面的技术：Vue、React、Svelte、Solid、甚至纯 HTML。核心原因是 WebView 只需要加载构建产物，框架本身无感知。本篇讲三个主流框架的接入要点、常见坑以及框架选择建议。

一、接入的本质：frontendDist

无论什么框架，接入方式都归结为两点：让构建产物输出到 Tauri 期望的目录，让开发服务器跑在 Tauri 期望的地址。在 tauri.conf.json 中：

{
  "build": {
    "frontendDist": "../dist",
    "devUrl": "http://localhost:1420",
    "beforeDevCommand": "npm run dev",
    "beforeBuildCommand": "npm run build"
  }
}

beforeDevCommand 与 beforeBuildCommand 让 Tauri 自动调起前端的构建或服务。不同框架只需改对应的端口与产物目录，其余完全一致。脚手架 create-tauri-app 已内置常见框架模板，新建项目时选择即可，不用手动改这些。

框架	默认端口	产物目录
Vue (Vite)	1420	dist
React (Vite)	1420	dist
Svelte (Vite)	1420	dist
Vue CLI	8080	dist

二、Vue 接入要点

Vue 加 Vite 的组合最省心。调用 Tauri API 的官方包是 @tauri-apps/api，建议在组合式函数里统一封装：

import { invoke } from '@tauri-apps/api/core'

export function useGreeting() {
  const greet = async (name) => {
    return await invoke('greet', { name })
  }
  return { greet }
}

Vue 项目里常见的问题是开发服务器与 tauri dev 的启动顺序。Tauri 会执行 beforeDevCommand 并等待 devUrl 可访问，因此 Vite 端口必须与配置一致。改端口时两边一起改，避免窗口打开后一直白屏。

三、React 与 Svelte 接入要点

React 模板默认使用 Vite，调用方式与 Vue 几乎相同。注意 invoke 返回的是 Promise，在组件里配合 useEffect 与状态钩子处理：

import { invoke } from '@tauri-apps/api/core'
import { useEffect, useState } from 'react'

function App() {
  const [version, setVersion] = useState('')

  useEffect(() => {
    invoke('app_version').then(setVersion)
  }, [])

  return <p>当前版本：{version}</p>
}

Svelte 的接入同样简单，差异主要在前端生态和团队偏好。三个框架在 Tauri 中的待遇完全一致，不存在哪个框架「更支持」Tauri 的说法。更多框架接入的官方模板清单以 Tauri 文档为准。

四、框架选择的实际因素

选框架时，Tauri 维度可以往后排，重点看这些：

因素	说明
团队熟悉度	会什么用什么，迁移成本最低
生态需求	重度 UI 库依赖时优先 React 或 Vue
包体积敏感	Svelte 与 Solid 产物更小
渲染一致性	系统 WebView 兼容性需实测

唯一需要留意的框架级问题是：某些依赖 Node polyfill 的库（比如访问 Node API 的包）在 WebView 里无法直接运行，需要替换为浏览器兼容版本，想深入排查可以用浏览器扩展指南的调度思路参照，里面也讲了 WebView 环境的差异排查。命令系统的完整细节见「前端调用 Rust：invoke 与命令系统」。

五、框架无关的最佳实践

无论选哪个框架，建议遵守三条：第一，把所有 invoke 调用集中到一个模块，便于统一加类型与错误处理；第二，事件监听在组件卸载时取消订阅，避免重复注册；第三，开发时关掉框架的严格模式带来的双重副作用，或至少理解其对 invoke 的影响。

类型安全方面可以在 Rust 端用 ts_rs 或 specta 之类的库从结构体生成 TS 类型，保持两端类型一致，具体库的用法以各自文档为准。也可以用 Claude Code 指南的方式让 AI 帮忙生成类型桥接代码，Rust 结构体侧的知识见 Rust 入门。

六、框架版本升级策略

前端框架升级节奏比 Tauri 快得多，混版是常见故障源。建议的策略是锁版本加定期升级：package.json 与 Cargo.toml 都锁到确切版本，每隔一个迭代窗口集中升级并跑回归测试。

依赖	锁定建议	升级频率
前端框架	主版本号	半年左右
@tauri-apps/api	与 tauri 主版本对齐	随 Tauri 升级
Rust crates	按 minor 锁定	需要新特性时
构建工具	跟随框架 LTS	框架升级时

特别强调一遍：@tauri-apps/api 的大版本必须与 Rust 端 tauri crate 的主版本一致，跨大版本混用会出现 invoke 路径、事件 API、权限声明全部对不上的离奇错误。升级 Tauri 时按官方迁移指南一步步来，不要自己猜改法。

框架接入的最后一公里是测试与调试。推荐在 CI 里跑前端单元测试加 Rust 集成测试两层：前端测试照旧，Rust 端可以把命令逻辑抽成纯函数单独测试，不依赖 Tauri 运行时。这种「逻辑与框架解耦」的写法本身也让代码更健康。接入框架只是起点，真正决定应用质量的是后续通信、状态与错误处理三件套，它们都在本站的后续章节里。

最后提一个混合场景：老 Electron 项目想局部迁移到 Tauri。可行的路子是把 Electron 的渲染层整体搬到 Tauri，主进程逻辑先保留为本地 HTTP 服务，Tauri 通过 Rust 的 HTTP 客户端调用，逐步把接口改写为命令。这条路的好处是每步可灰度、风险可控；坏处是过渡期维护两套逻辑，需要明确的收敛计划。无论是否迁移，理解两种架构的差异都让你在技术选型时更有底气，这也是本篇与架构对比章节相互呼应的地方。

框架接入完成后建议立刻补两件事：一套任何人都能一键跑起的构建流程，和一个展示全部典型 IPC 调用的示例页。示例页放一个输入框、一个按钮、一个结果区，串起命令与事件两套调用，看起来朴素却是团队里最实用的活文档。下一章正式讲命令系统，把这个示例页每个调用背后的机制讲透。

关于框架选择最后补充一条容易被忽视的维度：招聘与人才流动。团队最熟悉的框架就是成本最低的框架，这在中小团队里几乎是铁律。框架本身没有优劣，只有适不适合当前阶段：验证想法用最熟的，打磨体验用生态最强的，追求性能用产物最小的。这条判断同样适用于「是否引入 Tauri」本身——技术选型的核心从来不是追随潮流，而是在约束条件下做最合理的交换。带着这个视角重读本系列的架构对比章节，你会有更完整的判断框架。

最后一句忠告给所有框架接入工作：脚手架生成的模板代码值得逐行读懂，它是框架与 Tauri 对接的最佳实践样本，包含了构建配置、API 引入、窗口加载的全部约定。读懂模板的人能少走几个月弯路，直接把社区的集体经验变成自己的起点，这一点对任何技术栈都是通用的。

接入前端框架：Vue、React 与 Svelte

接入前端框架：Vue、React 与 Svelte

一、接入的本质：frontendDist

二、Vue 接入要点

三、React 与 Svelte 接入要点

四、框架选择的实际因素

五、框架无关的最佳实践

六、框架版本升级策略

延伸阅读