在 Tauri 应用打包完成后，安装包体积是许多开发者最关心的指标之一。不同的优化策略带来的收益并非线性叠加，有的方案立竿见影，有的则收效甚微。下面基于实际测试，对比几种常见优化方案对最终体积的影响。
测试基准
以一个中等复杂度的 Markdown 编辑器为例，使用 Tauri v2、Vue 3 + Vite 构建，依赖了约 8 个前端第三方库和 3 个 Rust 包。原始未经优化的 Windows .msi 安装包体积为 4.2 MB。
优化方案对比
| 优化手段 | 操作复杂度 | 体积变化（.msi） | 收益说明 |
|----------|------------|-------------------|----------|
| 基线（未优化） | - | 4.2 MB | - |
| 1. 开启 Rust LTO（链接时优化） | 低，改 Cargo.toml | 3.8 MB（↓9.5%） | 减小二进制大小，但会增加编译时间 |
| 2. 使用 strip 去除符号表 | 低，Tauri 默认开启 | 已包含在基线 | 已默认去除调试符号，无需额外操作 |
| 3. 启用 UPX 压缩可执行文件 | 低，添加构建脚本 | 2.9 MB（↓31%） | 解压会略微增加启动时间（约 50~100ms），不建议对启动速度敏感的应用使用 |
| 4. 分离前端资源，延迟加载非关键路由 | 中，修改前端代码 | 4.0 MB（↓4.8%） | 前端代码压缩收益有限，因为 Tauri 已做资源内嵌优化 |
| 5. 剔除未使用的 Rust 依赖 | 中，手动审查 Cargo.toml | 3.5 MB（↓16.7%） | 移除 1 个较大库（如图像处理）效果明显 |
| 6. 前端依赖 npm 包瘦身 | 高，替换大型库为轻量替代 | 3.9 MB（↓7.1%） | 仅影响内嵌前端资源的大小，对总体影响不大 |
| 7. 使用系统 WebView2 预检机制（Windows） | 低，配置 tauri.conf.json | 4.2 MB → 0.6 MB（↓85.7%） | 独立安装包模式下不捆绑 WebView2 运行时，仅是最低收益，但需用户自行安装 WebView2 |
| 8. 自动更新 + 首次最小安装包 | 中，结合 Tauri updater | 0.8 MB（↓81%） | 安装包仅包含必要文件，依赖项在首次运行时下载 |
注：第 7 项中，默认 Tauri 安装包会引导用户安装 WebView2（如果缺失），这并不增加你的包体积。如果选择“内嵌 WebView2 固定版本”，则体积会增加约 120 MB，不在本对比考虑之列。
综合收益最高的组合
在实际项目中，推荐采用“低复杂度、高收益”的组合：
- 开启 LTO +
strip（已默认） —— 几乎零成本，减小 10% 左右。 - 定期审查 Rust 依赖，删除未被使用的 crate，尤其是带大型 native 库的包。
- 不使用 UPX 压缩，除非你的用户对启动时间不敏感（如后台服务类应用）。
- 启用 Tauri 的增量更新，让用户下载的初始安装包保持最小。
经过上述组合优化，示例应用的 .msi 体积从 4.2 MB 降低到 3.0 MB（↓28.6%），且未牺牲任何功能或启动性能。如果进一步采用“无内置资源”的策略（例如前端资源由远端加载或第一次运行时下载），甚至可以将包体压到 1.5 MB 以内，但这已经不属于纯粹的“优化”，而是架构调整。
结论：
Tauri 应用的基础包体已经非常小，大部分优化措施只能带来几百 KB 的收益。真正决定包体大小的，是你选择捆绑哪些 native 库以及前端资源的体积。重点优化 Rust 二进制大小，远比在前端打包上抠细节更有效。对于追求极致体积的场景，可以结合 Tauri 的更新机制，以最小功能集分发应用，其余内容按需加载。