Tauri 应用从开发到打包要走哪些流程？

Tauri 应用的构建流程可以理解成两条线并行：前端先产出静态资源，Rust 再把 WebView、命令、权限和这些资源一起编进桌面应用。开发时它连着本地 dev server，打包时它读取前端构建目录；很多构建失败不是 Tauri 本身的问题，而是这两条线的路径、命令或系统依赖没有对齐。

构建前要确认哪些环境？

最少需要 Node.js、Rust stable、系统 WebView 依赖和 Tauri CLI。macOS 还要有 Xcode Command Line Tools；Windows 建议使用 MSVC 工具链；Linux 常见坑是缺 WebKitGTK、AppIndicator 或 OpenSSL 开发包。版本不要混着猜，先把命令固定到项目脚本里，CI 和本机都用同一套入口。

bash
rustup update stable
pnpm install
pnpm tauri dev
pnpm tauri build

Tauri v2 的配置重点是 beforeDevCommand、beforeBuildCommand、devUrl 和 frontendDist。开发模式读取 devUrl，生产包读取 frontendDist，如果前端框架输出目录从 dist 改成了 build，这里不改就会出现白屏。

json
{
  "productName": "DeskTool",
  "version": "1.0.0",
  "identifier": "com.example.desktool",
  "build": {
    "beforeDevCommand": "pnpm dev",
    "beforeBuildCommand": "pnpm build",
    "devUrl": "http://localhost:1420",
    "frontendDist": "../dist"
  },
  "bundle": {
    "active": true,
    "targets": ["dmg", "msi", "deb"],
    "icon": ["icons/icon.icns", "icons/icon.ico"]
  }
}

开发模式和生产打包有什么区别？

tauri dev 会启动前端开发服务器，然后编译 Rust 外壳，窗口里加载的是本地 URL，所以热更新快，但它不能代表最终安装包表现。tauri build 会先执行前端生产构建，再把静态文件打进应用资源目录，随后生成平台安装包。上线前至少要在生产包里走一遍登录、文件读写、自动更新、深链和权限弹窗，因为这些问题在 dev server 下经常被掩盖。

跨平台打包应该怎么安排？

Tauri 不是“一台机器打所有平台”最省心的方案。macOS 签名和 notarization 最好在 macOS runner 上做，Windows MSI/NSIS 放 Windows runner，Linux AppImage/deb 放 Ubuntu runner。交叉编译可以用 Rust target 解决一部分二进制问题，但安装包、系统依赖和签名链仍然强依赖目标平台。

yaml
strategy:
  matrix:
    os: [macos-latest, windows-latest, ubuntu-22.04]
steps:
  - uses: actions/checkout@v4
  - uses: pnpm/action-setup@v4
  - uses: dtolnay/rust-toolchain@stable
  - run: pnpm install --frozen-lockfile
  - run: pnpm tauri build

发布前还要检查哪些细节？

打包不是最后一个命令跑完就结束，真正麻烦的是安装后的表现。建议准备一张发布检查表：应用图标是否在三个平台都正常显示，配置文件是否写到用户目录，自动更新地址是否可访问，首次启动是否触发不必要的安全弹窗。前端静态资源也要用生产包验证，特别是字体、wasm、worker 和懒加载 chunk。

版本号需要同时关注前端 package、Tauri 配置和更新服务的 manifest。只改其中一个，用户看到的版本、安装包文件名和自动更新判断可能会不一致。这个问题平时不显眼，一到灰度发布就会拖慢排查。

还有一个容易忽略的点是资源路径。桌面包里的资源不再处于网站根目录，前端代码里写死 /assets/a.png、运行时再请求本地开发端口，都会在用户机器上失败。发布前最好断网打开安装包，确认核心页面不依赖开发环境。

如果应用带自动更新，还要检查更新包签名和下载地址。这个环节最好在测试环境完整跑一次。

追问

为什么本地 dev 能跑，build 后却白屏？

最常见原因是 frontendDist 指错了，或者前端用了只在开发服务器存在的路径。生产包里没有 Vite/Next 的 dev server，静态资源必须能从相对路径加载。取舍上，前端路由尽量使用 hash 或正确的 base 配置，少依赖服务端 fallback；踩坑点是 CSS、字体和懒加载 chunk 的绝对路径经常漏测。

macOS 签名和 notarization 可以最后再补吗？

内部测试包可以先不签名，但面向用户分发时不能拖到最后一天。签名会影响 entitlements、自动更新、网络权限和系统拦截提示，后补时容易发现包结构或权限模型要改。边界是企业内部分发和公开下载要求不同；公开下载建议尽早把 Developer ID、hardened runtime 和 notarization 放进 CI。

Windows 上 MSI 和 NSIS 应该选哪个？

MSI 更适合企业环境和集中管理，NSIS 的安装体验更灵活，也更容易做自定义页面。两者不是性能差异，而是分发场景不同。踩坑点是升级策略、安装路径和签名证书要提前定，否则用户机器上可能同时残留多个版本。

包体积应该在什么时候优化？

等功能稳定后再极限压缩更稳，因为 opt-level = "z"、LTO、strip 会拉长构建时间，也可能让调试信息变少。前期先控制前端依赖和图片资源，收益通常比折腾 Rust profile 更直接。边界是工具类应用用户更在意启动速度和下载体积，后台常驻应用则还要关注内存和更新包大小。

CI 构建失败先查哪里？

先看系统依赖和缓存，不要一上来怀疑业务代码。Linux runner 缺 WebKitGTK、Windows runner 没装正确 MSVC、macOS 证书没导入，是最常见三类问题。建议把 rustc -V、node -v、pnpm -v 和 Tauri 配置打印出来，排查会比盯着最后一行报错快很多。