8.2 多平台安装包与体积瘦身
出包环节的两件事：格式要对（不同渠道吃不同包），体积要省（轻量是选 Tauri 的初衷，别在交付环节丢掉）。本节过三平台安装格式的形态与适用，然后把体积账拆开算清，给一份带代价说明的瘦身清单。读完本节，你能对着渠道清单选包，并知道每一个 MB 花在了哪。
三平台包格式速查
| 平台 | 格式 | 形态与适用 |
|---|---|---|
| Windows | MSI | 企业风格，支持升级与组策略分发，工具链重 |
| Windows | NSIS | 向导式安装，体积更小，个人分发主流之选 |
| macOS | App 包加 DMG | 拖入 Applications 的经典形态，直分发标配 |
| Linux | AppImage | 单文件免安装，下载即跑，通用性最好 |
| Linux | deb 与 rpm | 发行版仓库路线，系统集成度最高 |
配置里 bundle 的 targets 控制"打哪些"：默认 all 打当前平台能打的全套；CI 矩阵里按平台显式列出更可控。Windows 双选是常见组合：NSIS 面向个人用户（体积小、引导顺），MSI 留给企业客户——两者可在同一构建同时产出。WebView2 引导是 Windows 特有项：面向老系统用户时，把 bundle 里 windows 段的 webviewInstallMode 配为下载引导（默认）或离线引导包（内嵌运行时，包体暴涨但零依赖），按用户群画像决定。
体积账：钱花在哪了
拿随身笔记的典型产物算一笔账（量级示意，随项目浮动）。NSIS 安装包约几 MB，其中大头依次是：Rust 二进制（含全部插件与依赖）、嵌入的前端产物、打包器外壳与图标资源。三个反直觉的事实：前端产物通常只占小头——几百 KB 的网页资产在原生二进制面前是零头；每多接一个插件都进二进制——7.1 领件时的"按需领取"在包体上兑现；未用代码也会进来——Rust 的泛型与宏会把依赖树里的代码带进来，链接器能删一部分但不能删全部。瘦身的三个着力点因此明确：编译配置、依赖面、前端产物。
图 8-2：安装包构成与瘦身着力点
瘦身清单：参数、收益与代价
Cargo 的 release 配置是瘦身主战场，逐项过：
# src-tauri/Cargo.toml [profile.release] opt-level = "s" # 优化目标改"体积最小"，默认 3 是"速度最快" lto = true # 链接期优化：跨 crate 删除死代码，编译更慢 strip = true # 剥离符号表与调试信息 codegen-units = 1 # 单编译单元：优化更彻底，编译时间翻倍级上升 panic = "abort" # panic 直接终止，去掉展开栈的运行时代码
代价与收益对照着看：opt-level 改 s——包更小、运行略慢，桌面应用的界面逻辑通常感知不到；lto 与 codegen-units=1——两者的瘦身与运行收益都实在，代价全在编译时间（CI 上多几分钟，可接受）；panic 改 abort——省体积，但 panic 不再能被捕获，"进程不能死"的常驻应用慎用（托盘常驻的随身笔记就不用这条）。三项配置合起来，二进制的缩减幅度可观，是"必做项"；下面的"选做项"按项目取用：清理 Cargo 特性（tauri 与各插件的 feature 全开不如按需）、审计依赖（cargo 的依赖树工具找重复大件）、前端侧开压缩与分包。
先量再瘦：把体积称出来
清单不是闭眼执行，先立基线。走一遍随身笔记的实测：优化前的 NSIS 包记录为基线值，然后逐项改动、逐次打包、逐次记录——表格只有三列（改动、包体、变化量），五分钟的工作量，换来的是每个决策都有数字背书。跳过这一步的常见结局是"做了五项优化，说不清哪项有用"，甚至出现负优化（某项配置对当前依赖树根本无效）。
称完总量再拆构成。二进制侧，用 cargo 的体积分析工具看"哪个 crate 占了多少"，通常能揪出 unexpected 的大件——某例里一个只为一个小函数引入的通用工具库占掉了可观份额，换成手写的同功能小函数后直接砍掉。前端侧，构建器的产物分析插件能给 dist 目录画出构成图，看不见的重灾区通常是：整字体（其实只用几十个字形）、未压缩图片、被整包引入的组件库。嵌入资源侧，检查静态资源目录有没有"顺手的行李"——示例数据、高清壁纸、调试用的样本文件混进资源目录，会原样进包。
| 冤枉重的来源 | 典型占比 | 处置 |
|---|---|---|
| 整套字体文件 | 数 MB 级 | 子集化，只留实际字形 |
| 未按需裁剪的图标库 | 数百 KB 起 | 按需导入或本地化所需图标 |
| 示例与调试资源混入产物 | 视项目而定 | 产物目录白名单化，构建前清理 |
| 全开的插件特性 | 每个 KB 到 MB 级 | 对照 7.1 的领料单逐个回收 |
实测里最有效的往往不是编译参数而是这几类"行李清理"——编译参数优化的是二进制本体，行李清理拿走的是根本不该上车的货。两类手段不互斥：先把行李清了，再上 release 配置，基线数字的变化曲线也最好看。
渠道包的额外考虑
上架应用商店是另一套账：Mac App Store 要求沙箱与商店签名（6.4 提到的类型不同的证书），包结构有额外要求；Microsoft Store 接受特定打包形态，转化链路不同。商店包与直分发包不通用——决定双渠道就双配置，别在最后一周才发现要重做。直分发的最后一块是增量更新的选择：8.3 的 updater 全量替换，包小时全量即可；包长大后可评估差分方案——这又回到瘦身：包体小，更新才轻。
本节要点回顾
- 格式对渠道：NSIS 面个人、MSI 面企业、DMG 直分发、AppImage 免安装、deb 与 rpm 进仓库；
- WebView2 引导模式按用户群选：默认在线引导，受控环境才内嵌；
- 体积大头是 Rust 二进制：插件按需领、特性按需开；
- 瘦身必做三项：opt-level s、lto 加 strip、codegen-units 1；panic abort 按应用形态取舍；
- 先测基线再优化，每项改动打包对比，渠道包双配置分立。
包出了、瘦了。下一关修上路：把 1.1 安全地送到装着 1.0 的用户手上。