Tauri 2 配置文件 tauri.conf.json 详解：app、build、bundle 三大分区

本节目标：读懂 Tauri 2 的主配置文件 tauri.conf.json，清楚 app、build、bundle 三大分区各自管什么，能照着改窗口、改名字、改打包目标。

上一章提到，tauri.conf.json 是 Tauri 应用的「总开关」。它用 JSON 写成，默认格式就是 JSON。Tauri 2 把配置整理成三大顶层分区：app、build、bundle。这一章我们就按这三个分区，把常用字段逐个讲明白。

配置文件的默认格式

Tauri 配置默认是纯 JSON。如果你更喜欢带注释的写法，可以在 Cargo.toml 里给 tauri 和 tauri-build 加上 config-json5 或 config-toml 功能，从而改用 JSON5 或 TOML。三者结构完全一致，只是语法不同：

[build-dependencies]
tauri-build = { version = "2.0.0", features = [ "config-json5" ] }

[dependencies]
tauri = { version = "2.0.0", features = [ "config-json5" ] }

JSON5 和 TOML 都允许写注释，调试配置时更顺手。不过本章示例统一用默认的 JSON，方便你直接对照脚手架生成的文件。

Note

除了主配置，还可以放平台专属文件，比如 tauri.windows.conf.json、tauri.macos.conf.json，它们会按 JSON Merge Patch 规则合并进主配置。多平台打包需要不同图标或资源时，这个机制很实用。

build 分区：开发时怎么跑前端

build 分区管的是「开发期」和「构建期」前后端怎么衔接。最关键的两个字段：

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

devUrl 是开发时前端服务的地址，Tauri 在 tauri dev 下会去加载这个地址的页面。beforeDevCommand 是在启动开发前要先执行的命令，通常用来拉起 Vite 之类的开发服务器。beforeBuildCommand 和 frontendDist 则对应打包：先跑构建命令，再把 frontendDist 指向的目录（前端打包产物）嵌进应用。

换句话说，build 分区回答的是两个问题：开发时去哪个网址看页面？打包时前端产物放在哪？

app 分区：应用身份与窗口

app 分区描述应用自身的身份和运行时行为，是平时改得最频繁的地方之一。最小可运行的样子：

{
  "app": {
    "productName": "my-tauri-app",
    "version": "0.1.0",
    "identifier": "com.example.my-tauri-app",
    "windows": [
      {
        "title": "My Tauri App",
        "width": 800,
        "height": 600,
        "resizable": true,
        "fullscreen": false
      }
    ]
  }
}

productName 是最终显示给用户的应用名，也决定生成的可执行文件叫什么。version 是版本号，打包和更新都靠它。identifier 是反向域名格式的唯一标识，前面章节讲过，它是系统在安装、升级时区分应用的依据，务必保持全局唯一。

windows 是一个数组，描述应用启动时的窗口。你可以设标题（title）、初始宽高（width/height）、是否可缩放（resizable）、是否全屏（fullscreen）等。数组里放多个对象，就能开多个窗口；只放一个，就是最常见的单窗口应用。

Tip

identifier 建议用你真正拥有的域名倒写，例如公司域 example.com 对应 com.example.应用名。它一旦发布就很难更改，早期就想好能省掉后续麻烦。

bundle 分区：怎么打包成安装包

bundle 分区管「分发」：产物叫什么、打哪些平台格式、用哪些图标。常见配置：

{
  "bundle": {
    "active": true,
    "targets": ["nsis", "msi"],
    "icon": [
      "icons/32x32.png",
      "icons/128x128.png",
      "icons/icon.icns",
      "icons/icon.ico"
    ],
    "identifier": "com.example.my-tauri-app"
  }
}

active 为 true 时，tauri build 才会产出安装包。targets 是目标平台格式列表：Windows 上常用 nsis（生成 .exe 安装包）和 msi（生成 .msi）；macOS 有 app、dmg；Linux 有 deb、rpm、appimage 等。写 ["all"] 则一次性产出当前平台支持的所有格式。

icon 是图标文件路径数组，不同格式（png/icns/ico）供不同系统取用。identifier 在这里也可以再写一次，和 app 分区保持一致即可。

Warning

不同系统的 targets 取值不互通：在 Windows 上配 deb 是没用的，因为那个平台根本打不出 Linux 包。打包目标要和你当前操作系统匹配，跨平台构建需要用对应系统的机器或 CI。

一个完整的最小示例

把三个分区合起来，一个可运行的 tauri.conf.json 长这样（字段已精简到最小可用集）：

{
  "productName": "my-tauri-app",
  "version": "0.1.0",
  "identifier": "com.example.my-tauri-app",
  "build": {
    "beforeDevCommand": "npm run dev",
    "devUrl": "http://localhost:5173",
    "beforeBuildCommand": "npm run build",
    "frontendDist": "../dist"
  },
  "app": {
    "windows": [
      {
        "title": "My Tauri App",
        "width": 800,
        "height": 600
      }
    ]
  },
  "bundle": {
    "active": true,
    "targets": ["nsis"],
    "icon": [
      "icons/32x32.png",
      "icons/128x128.png",
      "icons/icon.icns",
      "icons/icon.ico"
    ]
  }
}

注意 productName、version、identifier 在 Tauri 2 里是顶层字段，不再像 1.x 那样塞在 tauri 对象下——这是 2.x 配置结构重组的一部分。

Note

想查全部可选项，官方有完整的配置参考（config schema）。写复杂配置前翻一下，能少走很多弯路。本教程只讲最常用的字段，避免一上来被上百个选项淹没。

改了配置要不要重启

tauri.conf.json 是在「启动时」被读取并编译进应用的，所以绝大多数字段改完都需要重跑 tauri dev 才能生效，不像前端那样能热更新。只有少数运行期可调的项（例如通过 Rust 代码动态改窗口大小）例外。养成习惯：动了这个文件，就重启开发命令。

两个最容易填错的地方

新手常在两处栽跟头。一是 build.devUrl 和实际前端服务器地址对不上：脚手架生成的 Vite 默认是 http://localhost:5173，若你改过前端端口，这里也要跟着改，否则开发窗口白屏。二是 bundle.icon 列出的图标文件在 icons/ 里实际不存在：打包时会直接报错，按报错提示把缺的图标补上即可。

Tip

想临时试一种配置又不想改原文件，可以用 --config 传一段 JSON 合并进去，例如 tauri build --config '{"identifier":"com.example.beta"}'，适合打测试包、换名字等临时需求。

小结

到这章为止，你已经知道项目怎么建、文件怎么摆、配置怎么写。我们拆解了 tauri.conf.json 的三大分区——build（前后端衔接）、app（应用身份与窗口）、bundle（打包分发），并了解了平台专属配置覆盖、--config 临时合并等实用技巧。下一章我们真正把应用「跑」起来，看看开发模式窗口和热更新是怎么回事。