1. 项目概述：为什么Tauri打包Windows应用需要专门配置中文界面？

最近在折腾一个用Tauri开发的桌面小工具，功能都跑通了，准备打包发给团队里的同事用。结果一打包成Windows的exe，问题来了：安装界面、安装路径选择、甚至应用内的一些系统弹窗，全是英文的。团队里有些同事对英文界面不太熟悉，跑来问我能不能弄成中文的。这让我意识到，对于面向中文用户的应用，本地化不仅仅是应用内部文本的翻译，安装和部署过程的体验同样重要。一个全英文的安装向导，可能会让一部分用户感到困惑甚至放弃安装。

Tauri作为一个新兴的桌面应用开发框架，以其轻量、安全和现代的特性吸引了不少开发者，尤其是从Web前端转来做桌面应用的。它底层使用Rust，前端可以用你熟悉的任何框架（Vue、React、Svelte等）。但当我们把目光从开发环境移到最终的用户交付环境时，特别是Windows平台，就会遇到本地化这个“最后一公里”的问题。默认情况下，Tauri使用其内置的NSIS（Nullsoft Scriptable Install System）或WiX工具链生成的安装包，其界面语言依赖于构建环境的系统语言设置，或者就是简单的英文。这显然不符合我们对专业交付的要求。

所以，这个项目的核心目标很明确：为Tauri打包生成的Windows安装程序（exe），配置完整的中文界面。这包括安装向导的每一步提示、按钮文字、许可协议显示、安装路径选择界面等所有系统级文本。实现这个目标，不仅仅是改个配置那么简单，它涉及到对Tauri构建流程、Windows安装程序打包原理，以及NSIS脚本定制化的深入理解。下面，我就把自己趟过的路、踩过的坑，以及最终稳定的解决方案，完整地分享出来。

2. 核心思路拆解：从默认打包到中文定制的路径选择

要解决中文界面问题，我们首先得搞清楚Tauri默认是怎么打包Windows应用的。Tauri提供了tauri build命令，在Windows上，它会根据tauri.conf.json配置文件中的bundle设置，调用相应的打包工具。默认（且推荐）的打包器是NSIS，因为它免费、开源且脚本能力强大。

默认流程下，Tauri会使用一个内置的、预编译的NSIS脚本模板来生成安装程序。这个模板是“通用”的，其界面语言通常由NSIS安装程序在运行时根据操作系统的语言设置自动选择。如果系统语言是中文，且NSIS的多语言包中包含了中文，那么安装界面可能会显示为中文。但这里有几个不稳定因素：

1. 依赖用户系统：我们希望安装包本身“携带”中文界面，而不是依赖目标电脑的环境。
2. 内置模板可能不完整：Tauri内置的NSIS模板可能没有完整集成多语言支持，或者集成的语言文件版本较旧。
3. 无法自定义：对于“许可协议”等需要嵌入自定义中文文本的地方，默认流程无能为力。

因此，我们的核心思路从“依赖默认”转变为“主动定制”。具体有两条路径：

路径一：深度定制NSIS脚本。这是最彻底、最灵活的方法。我们需要告诉Tauri：“不要用你内置的那个通用脚本，用我提供的、专门为中文优化过的脚本。” 这需要我们理解NSIS脚本的基本结构，学会如何嵌入中文语言文件，以及如何修改脚本以正确加载这些语言。这种方法功能强大，可以精细控制安装过程的每一个细节，但门槛稍高，需要学习NSIS的语法。

路径二：利用Tauri的配置和社区插件。这是一种相对折中的方法。Tauri的配置文件tauri.conf.json提供了一些有限的安装程序定制选项。同时，社区也有一些插件或方案，可以简化多语言配置。这种方法更“Tauri原生”，改动点主要在配置层面，但灵活性和功能可能不如直接修改脚本。

经过实践，我发现对于“中文界面”这个强需求，尤其是希望安装包在任何Windows系统上都显示中文，路径一（定制NSIS脚本）是更可靠、更专业的方案。路径二往往无法解决所有问题，或者方案比较隐蔽。接下来，我们就深入这条“硬核”但一劳永逸的路径。

3. 环境准备与项目基础配置

在开始修改脚本之前，确保你的开发环境是就绪的。这里假设你已经有一个可以成功运行和打包的Tauri项目。

3.1 确认Tauri项目结构

一个典型的Tauri项目目录结构如下：

your-app/ ├── src-tauri/ │ ├── Cargo.toml # Rust 项目配置 │ ├── tauri.conf.json # Tauri 核心配置文件 │ ├── src/ │ │ └── main.rs # Rust 入口文件 │ └── target/ # 构建输出目录 ├── src/ # 你的前端代码（Vue/React等） └── package.json # 前端项目配置

我们所有关于打包的配置，都集中在src-tauri/tauri.conf.json这个文件里。

3.2 关键配置项检查

打开tauri.conf.json，找到"bundle"部分。我们需要关注"windows"下的"nsis"配置。

{ "tauri": { "bundle": { "identifier": "com.yourcompany.app", "targets": ["nsis"], "windows": { "nsis": { // 这是NSIS相关的配置区域 } } } } }

在开始定制前，请先确保用默认配置能成功打包出一个exe安装程序。在项目根目录运行：

cd src-tauri cargo tauri build

或者在前端根目录运行：

npm run tauri build

如果打包成功，你会在src-tauri/target/release/bundle/nsis/目录下找到生成的.exe安装文件。双击运行它，观察默认的安装界面是什么语言。这将是我们的“基线”。

注意：首次构建可能会下载NSIS等工具，时间较长。确保网络通畅。另外，Windows上构建需要安装Microsoft Visual C++构建工具和Rust的x86_64-pc-windows-msvc工具链，这是Tauri for Windows的默认要求。

4. 核心实战：定制NSIS脚本实现中文安装界面

这是整个过程中最关键的一步。我们将创建一个自定义的NSIS脚本，并让Tauri在打包时使用它。

4.1 获取并准备中文语言文件

NSIS支持多语言，其语言定义以.nsh头文件的形式存在。官方已经包含了简体中文（SimpChinese）和繁体中文（TradChinese）的语言文件。我们通常使用简体中文。

1. 定位NSIS安装目录：如果你安装了NSIS（Tauri构建过程可能会自动安装或使用内置版本），可以在其安装目录下的Contrib\Language files里找到SimpChinese.nsh。例如，路径可能是C:\Program Files (x86)\NSIS\Contrib\Language files\SimpChinese.nsh。
2. 复制语言文件到项目：为了项目自包含，不依赖构建机器的NSIS路径，我们将这个文件复制到我们的Tauri项目中。在src-tauri目录下创建一个新的文件夹，比如叫nsis，然后把SimpChinese.nsh复制进去。

   src-tauri/ ├── nsis/ │ └── SimpChinese.nsh ├── Cargo.toml └── tauri.conf.json

4.2 创建自定义NSIS脚本

接下来，在src-tauri/nsis/目录下，创建一个新的文本文件，命名为installer.nsi。这个文件就是我们自定义的安装脚本。

我们需要基于Tauri默认的NSIS逻辑，但加入多语言支持。一个最基础的支持中文的脚本框架如下：

; 定义应用信息，这些变量通常会被Tauri构建过程自动替换 !define APP_NAME "YourAppName" !define COMPILER_NAME "Tauri" !define APP_VERSION "1.0.0" !define APP_PUBLISHER "YourCompany" !define APP_EXECUTABLE "your-app.exe" !define INSTALLER_NAME "${APP_NAME}-${APP_VERSION}-setup.exe” ; 引入多语言支持宏 !include "MUI2.nsh” ; 引入简体中文语言文件 !include "nsis\SimpChinese.nsh” ; 设置安装程序的基本属性 Name "${APP_NAME}" OutFile "${INSTALLER_NAME}" InstallDir "$PROGRAMFILES64\${APP_NAME}" ; 默认安装到64位程序目录 ShowInstDetails show ShowUninstDetails show RequestExecutionLevel admin ; 可能需要管理员权限 ; 设置界面语言为简体中文 !insertmacro MUI_LANGUAGE "SimpChinese” ; 安装程序页面配置 !insertmacro MUI_PAGE_WELCOME ; 欢迎页面 !insertmacro MUI_PAGE_LICENSE "$(MUILicense)" ; 许可协议页面，文本需额外提供 !insertmacro MUI_PAGE_DIRECTORY ; 选择安装目录页面 !insertmacro MUI_PAGE_INSTFILES ; 安装过程页面 !insertmacro MUI_PAGE_FINISH ; 完成页面 ; 卸载程序页面配置 !insertmacro MUI_UNPAGE_WELCOME !insertmacro MUI_UNPAGE_CONFIRM !insertmacro MUI_UNPAGE_INSTFILES !insertmacro MUI_UNPAGE_FINISH ; 设置安装目录 Section "MainSection" SEC01 ; 这里会由Tauri自动填充文件复制等逻辑 ; 我们主要目的是控制界面语言，所以核心逻辑可以保留占位符 SetOutPath "$INSTDIR" ; ... 文件复制等操作将由Tauri生成 SectionEnd ; 以下部分用于处理Tauri自动生成的脚本片段 ; Tauri在构建时，会将其生成的脚本内容插入到特定的标记位置 ; 我们需要在脚本中预留这些标记 ; 标记：Tauri会在这里插入安装/卸载文件列表和操作 !macro TAURI_INSTALLER_MAIN !macroend !macro TAURI_UNINSTALLER !macroend

这个脚本做了几件关键事：

1. !include "MUI2.nsh"：引入了NSIS的现代用户界面2库，它提供了美观的安装向导界面。
2. !include "nsis\SimpChinese.nsh"：引入了我们准备好的简体中文语言文件。
3. !insertmacro MUI_LANGUAGE "SimpChinese"：这是最关键的一行。它告诉安装程序，使用简体中文作为界面语言。这个宏必须在所有页面定义之后、但在Section之前调用。
4. 定义了标准的安装向导页面（欢迎、许可、目录、安装、完成）。
5. 预留了!macro TAURI_INSTALLER_MAIN和!macro TAURI_UNINSTALLER宏。Tauri在构建时，会寻找这些宏，并将其内部生成的、用于处理实际文件复制、创建快捷方式、写入注册表等操作的脚本代码插入进来。

实操心得：直接从头编写一个功能完整的NSIS脚本对接Tauri的打包输出是比较复杂的，因为Tauri需要自动管理应用文件、资源、图标等。上述方法是一种“混合”模式：我们提供一个外壳脚本（控制语言和页面），让Tauri把核心逻辑“注入”进来。这是与Tauri协作最稳妥的方式。

4.3 配置Tauri使用自定义脚本

现在，我们需要修改tauri.conf.json，告诉Tauri：“请使用我提供的installer.nsi脚本，而不是你内置的模板。”

在tauri.conf.json的nsis配置部分，添加或修改script字段：

{ "tauri": { "bundle": { // ... 其他配置 ... "windows": { "nsis": { // 指定自定义NSIS脚本的相对路径（相对于tauri.conf.json） "script": "../nsis/installer.nsi", // 可选：是否启用压缩，推荐开启以减小安装包体积 "compress": true, // 可选：是否创建一键安装模式（无界面），根据需求设置 "oneClick": false, // 可选：是否允许用户更改安装目录，false则为静默安装到默认目录 "allowToChangeInstallationDirectory": true, // 可选：安装包图标，路径相对于tauri.conf.json // "installerIcon": "./icons/installer.ico", // 可选：卸载程序图标 // "uninstallerIcon": "./icons/uninstaller.ico" } } } } }

关键就是"script": "../nsis/installer.nsi"这一行。它指向我们刚才创建的自定义脚本。

4.4 处理许可协议等自定义文本

你可能注意到，在脚本中我们有一个MUI_PAGE_LICENSE页面，它显示许可协议。默认情况下，这个页面的文本是空的。我们需要提供一个中文的许可协议文件。

1. 在src-tauri/nsis/目录下，创建一个文本文件，例如license_zh_CN.txt。将你的软件许可协议（必须是纯文本格式）内容粘贴进去，并确保是中文。
2. 修改installer.nsi脚本，在定义语言之后，指定许可协议文件。在!insertmacro MUI_LANGUAGE "SimpChinese"这行后面添加：

   ; 指定许可协议文件 LicenseLangString MUILicense ${LANG_SIMPCHINESE} "nsis\license_zh_CN.txt”

   LicenseLangString命令将语言${LANG_SIMPCHINESE}（即简体中文）下的许可协议字符串MUILicense与文件nsis\license_zh_CN.txt关联起来。这样，当安装程序以中文运行时，就会自动加载这个文件显示。

4.5 执行构建并验证

完成以上步骤后，再次运行打包命令：

npm run tauri build

这次构建，Tauri会读取你的installer.nsi脚本作为模板。观察构建日志，如果没有NSIS语法错误，构建会成功。

构建完成后，再次找到生成的exe安装程序（路径通常在src-tauri/target/release/bundle/nsis/），双击运行。现在，你应该能看到一个完全中文界面的安装向导了，包括欢迎页、许可协议（显示你提供的中文文本）、安装目录选择页等。

5. 进阶配置与深度优化

实现了基本的中文界面后，我们还可以进行一些优化，让安装包更专业、更符合Windows应用规范。

5.1 自定义安装包图标和产品信息

安装包本身也是一个exe文件，拥有自己的图标。在tauri.conf.json的nsis配置中，我们已经看到了installerIcon和uninstallerIcon的配置项。你需要准备两个ICO格式的图标文件（建议尺寸包含256x256, 128x128, 64x64, 48x48, 32x32, 16x16），并指定正确的路径。

此外，我们还可以在NSIS脚本中定义更详细的产品信息，这些信息会写入Windows的“添加或删除程序”（或“应用和功能”）列表中。修改installer.nsi脚本的开头部分：

; ... 之前的定义 ... ; 设置安装程序元信息，这些会显示在“应用和功能”中 VIProductVersion "${APP_VERSION}.0" ; 版本格式为 X.X.X.X VIAddVersionKey "ProductName" "${APP_NAME}" VIAddVersionKey "FileVersion" "${APP_VERSION}" VIAddVersionKey "ProductVersion" "${APP_VERSION}" VIAddVersionKey "CompanyName" "${APP_PUBLISHER}" VIAddVersionKey "FileDescription" "${APP_NAME} Installer" VIAddVersionKey "LegalCopyright" "© ${APP_PUBLISHER}” ; ... 之后的 !include 和页面配置 ...

这样，用户在系统设置里查看已安装的应用时，就能看到规范的中文应用名、版本和发布者信息。

5.2 处理卸载程序的中文化

我们上面的脚本已经配置了卸载程序的页面（MUI_UNPAGE_*系列宏）。由于我们在脚本开头就通过!insertmacro MUI_LANGUAGE "SimpChinese"设置了语言，所以卸载程序的界面也会自动是中文，无需额外配置。这一点非常方便。

5.3 应对复杂的安装逻辑

如果你的应用安装过程需要更复杂的逻辑，比如检查运行环境（.NET Framework, VC++ Redistributable）、创建桌面快捷方式、安装后运行应用等，你可以在自定义的installer.nsi脚本的Section部分添加相应的NSIS命令。

例如，在Section段落的末尾，添加创建桌面快捷方式的命令：

Section "MainSection" SEC01 SetOutPath "$INSTDIR” ; ... Tauri自动生成的文件复制命令 ... ; 创建桌面快捷方式 CreateShortCut "$DESKTOP\${APP_NAME}.lnk" "$INSTDIR\${APP_EXECUTABLE}" SectionEnd

或者，在安装完成后运行应用的命令（谨慎使用，可能干扰用户）：

!define MUI_FINISHPAGE_RUN "$INSTDIR\${APP_EXECUTABLE}" !insertmacro MUI_PAGE_FINISH

这些定制都需要你对NSIS脚本语法有一定的了解。NSIS官方文档和社区资源非常丰富，可以按需查阅。

6. 常见问题排查与实战技巧

在实际操作中，你可能会遇到各种各样的问题。下面是我总结的一些常见坑点和解决方法。

6.1 构建失败：NSIS脚本语法错误

这是最常见的问题。错误信息通常会在cargo tauri build的输出中看到，指向你的installer.nsi文件的某一行。

排查步骤：

1. 检查路径和引号：NSIS对路径中的反斜杠\和正斜杠/有时比较敏感。在!include和文件路径中，使用双反斜杠\\或正斜杠/通常更安全。确保所有文件路径都正确。
2. 检查宏的顺序：NSIS的MUI2宏调用顺序有严格要求。通常是：定义页面 -> 设置语言 -> 实例化页面。确保!insertmacro MUI_LANGUAGE在页面宏定义之后。
3. 验证语言文件：确保你复制的SimpChinese.nsh文件是完整的，没有损坏。可以尝试用文本编辑器打开，看看里面是否是正常的NSIS语言定义代码。
4. 简化脚本：如果遇到复杂错误，可以先注释掉所有自定义内容，只保留最基本的脚本框架（引入MUI2、设置语言、定义页面），让Tauri先能跑通。然后逐步取消注释，定位问题代码。

6.2 安装界面仍是英文或乱码

如果安装程序运行后界面不是中文，或者是乱码（方框），说明语言加载失败了。

排查步骤：

1. 确认语言宏已调用：确保!insertmacro MUI_LANGUAGE "SimpChinese"这行代码存在，并且没有被包含在任何条件判断或函数里，它应该在脚本的全局作用域被调用。
2. 检查语言文件编码：SimpChinese.nsh和license_zh_CN.txt等包含中文的文本文件，必须保存为UTF-8 with BOM编码。这是NSIS正确识别中文的关键。用Notepad++或VSCode等编辑器可以轻松转换和查看编码。
   • 在VSCode中，点击右下角的编码（如“UTF-8”），选择“通过编码保存”，然后选择“UTF-8 with BOM”。
3. 检查Tauri构建缓存：有时Tauri或NSIS会缓存旧的脚本或资源。尝试清理构建缓存：

   # 删除Tauri的target目录（注意：这会清理所有构建产物） cd src-tauri cargo clean # 然后重新构建 npm run tauri build

6.3 许可协议页面不显示中文文本

如果其他界面是中文，但许可协议页面是空白或英文。

排查步骤：

1. 检查LicenseLangString命令：确保LicenseLangString命令在设置语言（MUI_LANGUAGE）之后，且在页面实例化之前。命令中的文件路径要正确。
2. 检查许可协议文件：确保license_zh_CN.txt文件存在，路径正确，并且是UTF-8 with BOM编码。文件内容不要包含不兼容的特殊字符。
3. 尝试绝对路径：为了排除路径问题，可以暂时使用绝对路径测试，如"C:\your\project\src-tauri\nsis\license_zh_CN.txt"。

6.4 安装包体积或性能考虑

Tauri应用本身以轻量著称，但NSIS安装包可以进行压缩以进一步减小体积。tauri.conf.json中的"compress": true默认是开启的，它使用NSIS的压缩器。如果你对体积有极致要求，可以尝试NSIS的其他压缩插件（如LZMA），但这需要在自定义脚本中更底层的配置，相对复杂。对于大多数应用，默认压缩已经足够。

6.5 与Tauri版本兼容性

Tauri的构建流程和NSIS集成方式在不同版本间可能会有细微变化。本文所述方法基于Tauri 1.x版本。如果你使用的是其他版本，建议先查阅对应版本的官方文档中关于Windows > nsis > script配置的说明。核心原理（提供自定义脚本、引入语言文件、设置语言）是通用的，但配置项名称或脚本注入的宏名称可能会有调整。

7. 总结与最终建议

为Tauri应用配置一个纯中文的Windows安装界面，从“能用”到“专业”，这最后一步的体验提升非常明显。整个过程的核心在于理解Tauri的打包是可定制的，尤其是通过覆盖默认的NSIS脚本。

回顾一下最关键的操作流程：

1. 准备：从NSIS安装目录获取SimpChinese.nsh，放入项目。
2. 创建：编写自定义的installer.nsi脚本，核心是!include语言文件和!insertmacro MUI_LANGUAGE "SimpChinese"。
3. 配置：在tauri.conf.json中通过"script"字段指向你的自定义脚本。
4. 细化：通过LicenseLangString提供中文许可协议，通过VIAddVersionKey完善产品信息。
5. 构建与验证：清理缓存后重新构建，并运行生成的安装包进行测试。

我个人在实际操作中的体会是，编码问题（UTF-8 with BOM）和脚本宏的调用顺序是两大最常见的“拦路虎”。一旦跨过这两个坎，后面就一马平川了。另外，不要害怕直接阅读和修改NSIS脚本，它虽然是一门小众语言，但语法直观，社区案例丰富，稍微花点时间就能掌握基础，这能帮你解决很多高级定制需求。

最后，一个更工程化的建议：将nsis目录及其下的脚本、语言文件、许可文件都纳入你的版本控制系统（如Git）。这样，整个团队都能获得一致的中文打包体验，构建过程也不再依赖任何特定开发机上的环境配置，真正实现了可重复的构建。