16.3 更新服务搭建：版本检测、包分发、灰度发布

Windows：exe、msi、nsis 安装包配置

Tauri 在 Windows 平台上支持三种主流的安装分发格式：exe（便携执行文件）、msi（Windows Installer 包） 和 nsis（基于 NSIS 的安装向导）。在 tauri.conf.json 的 bundle 配置项中，你可以灵活选择生成哪一种或哪几种格式，以满足不同的分发场景。

1. exe（便携执行文件）

配置方式：在 tauri.conf.json 的 bundle > windows > wix 中设置（实际上 exe 是默认生成的基包），通常通过 tauri build 后直接在 target/release/bundle/msi 或 nsis 目录之外获得。
特点：无需安装，双击即可运行，适合临时使用、便携工具或开发者内部测试。
注意事项：exe 本身不包含 WebView2 运行时，若系统未安装 WebView2，应用会尝试自动下载安装（或需要额外分发引导程序）。同时 exe 没有卸载程序，删除文件夹即可。
适用场景：绿色软件、便携工具、内测版本快速分发。

2. msi（Windows Installer 包）

配置方式：在 tauri.conf.json 的 bundle 中，将 windows.wix.template 指向自定义的 WiX 模板，并确保 bundle.active: true。实际打包时执行 tauri build，TAURI 会调用 WiX 工具链生成 .msi 文件。
特点：微软官方安装格式，支持静默安装、组策略分发、权限提升、企业批量部署（SCCM/Intune）。安装过程受 Windows Installer 服务管理，可完整回滚。
配置文件示例：

  "bundle": {
    "active": true,
    "windows": {
      "wix": {
        "template": "path/to/custom.wxs",
        "language": "zh-CN"
      }
    }
  }

实用细节：需要安装 WiX Toolset v3 并确保 candle.exe 和 light.exe 在 PATH 中。模板文件可自定义安装目录、快捷方式、文件关联等。
适用场景：企业级部署、需要通过域推送或 MDM 分发的应用。

3. nsis（基于 NSIS 的安装向导）

配置方式：在 tauri.conf.json 中启用 bundle.windows.nsis。示例：

  "bundle": {
    "active": true,
    "windows": {
      "nsis": {
        "template": "path/to/installer.nsi"
      }
    }
  }

特点：生成轻量级的 .exe 安装程序，压缩率高，安装包体积小。可自定义安装过程界面、协议注册、环境变量等。
前置要求：需安装 NSIS（3.08 及以上），并将其目录加入 PATH。Tauri 会调用 makensis 生成安装包。
常见定制：通过 .nsi 模板可以加入许可协议页面、选择安装组件、创建桌面快捷方式、添加卸载程序等。Tauri 官方提供了默认模板可作为起点。
适用场景：面向普通用户的桌面应用安装程序，追求小巧且交互友好的安装体验。

如何选择？

如果只是内部快速测试，或希望用户“解压即用”，直接用 exe。
如果面向企业，需要受控部署和权限管理，选 msi。
如果面向大众消费者，需要专业的安装界面和小巧的包体积，选 nsis。

你可以在一次构建中同时开启多个格式，Tauri 会一次性生成所有需要的安装包，无需重复编译。

16.3 更新服务搭建：版本检测、包分发、灰度发布

Tauri 内置了 Updater 插件，可以方便地为应用添加自动更新能力。要搭建一个完整的更新服务，需要解决三个核心问题：如何检测新版本、如何分发更新包 以及 如何实现灰度发布。

1. 版本检测机制

Tauri 的 Updater 插件采用“静态文件服务”作为检查源。应用启动时（或定时轮询）会向一个固定的 URL 发送 GET 请求，下载一个 JSON 格式的更新清单文件（通常命名为 latest.json），并将其与本地的应用版本号对比。如果远端版本更高，则提示用户升级。

配置步骤：

在 tauri.conf.json 中启用 updater：

  "updater": {
    "active": true,
    "endpoints": [
      "https://your-update-server.com/update/{{target}}/{{arch}}/{{current_version}}"
    ],
    "dialog": true,
    "pubkey": "YOUR_PUBLIC_KEY"
  }

endpoints 中可以使用变量：{{target}}（操作系统）、{{arch}}（架构）、{{current_version}}。请求后会获得如下响应：

  {
    "version": "1.2.0",
    "notes": "修复了若干bug",
    "pub_date": "2024-01-01T00:00:00Z",
    "platforms": {
      "windows-x86_64": {
        "signature": "Content of .sig file",
        "url": "https://your-cdn.com/releases/1.2.0/windows/app-x86_64-setup.nsis.zip"
      }
    }
  }

签名验证：更新包必须使用私钥签名，并将公钥写入配置文件。生成密钥对使用 tauri signer generate -w ~/.tauri/myapp.key，然后分发 .sig 签名文件。这确保了更新包来源可信，防止中间人攻击。

2. 包分发方案

更新包通常较大（几十 MB），需要使用稳定的文件服务或 CDN 分发。

推荐方案：

对象存储 + CDN：将各平台的安装包上传到阿里云 OSS、AWS S3 等，开启 CDN 加速。url 字段直接指向 CDN 地址。
自建静态服务：使用 Nginx 提供静态文件，适合内网或小型团队。成本低，但需考虑带宽和并发。
GitHub Releases：对于开源项目，可以直接将包上传至 GitHub Releases，并使用 https://github.com/.../releases/latest/download/... 作为 URL。但需注意 API 频率限制，且国内访问可能较慢。

签名流程：
生成更新包后，使用之前生成的私钥签名：

tauri signer sign -k ~/.tauri/myapp.key update.zip
# 会生成 update.zip.sig

将 .sig 内容填入 JSON 的 signature 字段。

3. 灰度发布实现

灰度发布即按一定比例或按特定用户群分批次推送新版本，避免全量发布导致大面积故障。Tauri 官方 Updater 插件本身不支持内置的灰度策略，但我们可以通过动态生成更新清单服务器端实现。

实现思路：

搭建一个简单的后端服务（如 Node.js、Go、Python），根据请求中的参数（如用户 ID、设备 ID、地域、预定义灰度组等）动态返回不同的 latest.json。
在 endpoints 中携带灰度标识，例如：

  https://api.yourdomain.com/update?version={{current_version}}&uid={{uid}}

Tauri 支持在 endpoints 中使用自定义变量（需要在 Rust 端注入 env 或通过 Plugin 扩展，或直接在构建时写入固定值）。

后端根据 uid 的哈希值进行分桶，比如取前 10% 的用户返回新版本，其余用户返回当前稳定版本。当灰度验证稳定后，逐步扩大比例直至全量。
也可以利用 Tauri 的“单次构建多平台”特性，为不同渠道（测试版、稳定版）提供不同的更新端点，通过编译时特征区分。

实际案例：
假设我们要对 10% 的用户推送 v1.3.0-beta，其余用户仍为 v1.2.0：

用户请求 https://update.myapp.com/check?uid=bob&version=1.2.0
服务端计算 hash(uid) % 100，若小于 10 则返回 v1.3.0 的更新 JSON，否则返回空内容或提示已是最新版本。
前端代码无需改动，完全由服务端控制逻辑。

额外的安全与稳定性建议：

更新 JSON 文件必须通过 HTTPS 传输，防止被篡改。
签名验证是必须开启的，否则攻击者可伪造更新包。
对于重大更新，可以结合“最低支持版本”字段，强制旧版本必须更新才能继续使用服务。
在灰度期间，收集用户崩溃报告和反馈，确保新版本稳定后再全量推全。

通过上述组合，你就可以搭建出生产级别的自动更新服务，既能保证用户及时获得修复和功能，又能有效控制发布风险。