网页装不下就打包：vibe 项目的桌面应用（Electron/Tauri）打包实战

开篇先划界：这篇讲什么、不讲什么

本篇讲的是打包与分发，与站内三篇明确分工：vibe-project-dev-environment-standardization-guide（开发环境标准化）讲的是"本机开发环境"，本篇讲的是"交付给用户的安装包"——开发 vs 交付；vibe-project-self-hosting-guide（自托管）讲的是"服务端在哪跑"，本篇讲的是"客户端怎么装"；vibe-project-mobile-app-store-launch-guide（移动端上架）讲的是"手机商店审核"，本篇讲的是"桌面端打包分发"。

vibe 项目最常见的死亡姿势，不是代码写不出来，而是"在我电脑上能跑"之后就卡住了。你给朋友发了个 zip，他解压后问"双击哪个"；你发了个 GitHub 链接，对方说"我不会装 Node"。从"跑起来"到"装得上"，中间隔着一套完全独立的工种：打包、签名、公证、安装包瘦身、自动更新、跨平台构建。AI 能替你写业务代码，但替不了你回答"为什么用户双击 dmg 提示已损坏"。下面这份指南按真实交付顺序铺开：先判断值不值得打包，再选型，然后一步步做到用户能自动更新。

桌面应用交付管线图：源码、构建、打包、签名、分发与自动更新六个阶段

图 1：桌面应用交付管线——源码经过构建、打包、签名三道工序才变成可分发的安装包；自动更新是发布后的第二条生命线。红字标出了一人团队最常翻车的三个位置。

一、什么时候需要桌面端：网页装不下的 5 个场景

先泼冷水：大多数 vibe 项目不需要桌面端。浏览器已经足够好，打包是给"网页真的装不下"的需求准备的。下面 5 个场景，每一个都是浏览器 API 的硬边界：

1. 系统托盘常驻。剪贴板管理、截图贴图、番茄钟、网速监控——这类工具的本体就是"活在后台"。网页关掉标签页进程就没了，托盘应用可以没有窗口一直跑，右键菜单、气泡通知都是原生能力。

2. 全局快捷键。Alt+Space 唤起的启动器、划词翻译、全局截图 OCR。浏览器里你抢不到系统级热键——焦点在别的软件里时，你的网页连键盘事件都收不到。

3. 本地文件深度读写。批量重命名、本地视频转码、个人知识库建索引。浏览器 File System Access API 不是不能用，而是每次都要用户点授权、目录权限重启就丢；让用户对着 2 万个文件一个个点"允许"，等于劝退。

4. 真离线可用。飞机、高铁、客户现场的弱网。PWA 离线缓存能应付"看"，应付不了"干"——本地 SQLite + 文件系统 + 后台任务，才是真离线。断网还能全文检索自己 5 年的笔记，这种体验网页给不了。

5. 开机自启与后台任务。自动备份、定时同步、到点提醒。网页做不到开机自启，这是操作系统留给"已安装应用"的特权。

中了上面任意一条，打包才有意义。举个真实的一人团队例子：有人做了个本地 Markdown 知识库，网页版时用户抱怨"每次打开都要重新选文件夹授权"，打包成桌面应用后，文件夹权限一次授权永久有效，留存直接翻倍——同一个产品，形态换了，体验完全是两回事。

反过来，下面几种情况坚决别打包：纯内容型产品（博客、文档站、作品集）——安装门槛会杀死传播；需要 SEO 和分享链路的产品——安装包没有 URL；还在高频验证期、每天改三次方向的产品——打包、签名、公证、更新的发布节奏，追不上网页"git push 即上线"的即时性；以及团队里没人愿意碰证书续期、公证排队这种脏活——签名不是做一次就完，是每年续费、每版重签的持续成本。vibe 项目 90% 死在没人用，不是死在没打包。先让网页版跑出 100 个真实用户，再谈桌面端。

二、Electron vs Tauri：不给站队，给决策树

选型争论没有意义，有意义的是"你的约束是什么"。先看五维对照（Hello World 口径，2026 年实测对比数据）：

包体积：Electron 约 150MB（自带整个 Chromium），Tauri 约 3–15MB（调用系统 WebView）。这不是优化差距，是架构差距。内存占用（空闲）：Electron 200–400MB，Tauri 50–100MB。生态成熟度：Electron 高——十年生态，VS Code、Discord、Slack 都是它，遇到问题 Stack Overflow 上一定有答案；Tauri 中——2.x 已稳定（当前 2.12），插件生态在追，但冷门需求可能要自己写 Rust。学习成本：Electron 低——纯 JS/TS，Node 全家桶无缝衔接；Tauri 中——不写 Rust 也行，但配构建、读报错、调原生能力时迟早要面对 Rust。更新机制：两者都成熟——Electron 有 electron-updater（差分更新、灰度发布），Tauri 内置 updater（签名校验、latest.json 清单）。

对照表看完，走一遍决策树：你的团队能读 Rust 报错吗？不能 → Electron，别为难自己。包体积是生死线吗？（用户在弱网环境下载、产品本身就是个"小工具"）是 → Tauri，150MB 的"小工具"是笑话。需要调用复杂的本地能力吗？（串口、USB 设备、系统级钩子）→ Electron（Node 生态现成库多）或者 Tauri（自己写 Rust 插件，有 Rust 能力才选）。已经在用 Rust / 想借机学 Rust？→ Tauri。只想最快拿出第一个能装的版本？→ Electron，electron-builder 一条命令出三个平台的包。

选完之后别急着 all in：花半天时间用选定的方案打一个"最小安装包"——能装、能打开、能显示版本号就行。包体积、启动速度、第一个原生能力调用，三个指标实测一遍，选型才算落地。vibe 项目最贵的不是选错，而是选完三个月才发现装不上。

一句话版本：要快、要生态、团队纯前端 → Electron；要小、要省内存、有人能碰 Rust → Tauri。还有一条少有人说的：AI 写 Electron 配置的成功率明显高于 Tauri——Electron 的问答语料是 Tauri 的几十倍，vibe workflow 里"AI 一次写对"的概率本身就是选型因素。至于 Neutralinojs 这类更轻的方案（Hello World 不到 2MB），生态太薄、插件要自己造，只适合"公司内部小工具"这种场景，面向用户的产品别碰。

桌面应用交付管线图：源码、构建、打包、签名、分发与自动更新六个阶段

图 2：Electron vs Tauri 五维对照。包体积与内存是 Tauri 的绝对优势，生态与学习成本是 Electron 的主场，更新机制两者都已成熟。

三、最小可行打包：从 Web 项目到第一个 .dmg / .exe

目标很具体：今天下班前，你的项目能在另一台电脑上双击安装并跑起来。两条路线二选一，别混用。

Electron 路线（electron-builder v26，社区事实标准）。第一步装依赖：npm i -D electron electron-builder，写一个 30 行的 main 入口——建 BrowserWindow、loadFile 指向你 Vite 构建出的 dist/index.html，就这么多。第二步在 package.json 里加 build 段，三个字段决定生死：appId 用反域名（com.yourname.app，绝不能留 com.example 占位）、productName 显示名、files 白名单只含 dist/**/* 和必要资源，同时 asar: true 打开。第三步构建：npx electron-builder --mac dmg --win nsis --linux AppImage，产物在 dist/ 目录下。第一次跑大概率一次成功——electron-builder 的默认值是给新手准备的。

Tauri 路线（Tauri 2.x，当前 2.12）。已有 Vite 项目的话：npm i -D @tauri-apps/cli，跑 npx tauri init 生成 src-tauri/ 目录。核心是 tauri.conf.json：identifier 填反域名（和 Electron 的 appId 同一个作用）、bundle.targets 按平台写（mac 写 ["dmg", "app"]，win 写 ["nsis"]，linux 写 ["appimage", "deb"]，或者直接 "all"）。然后 npm run tauri build，它会先跑你的前端构建，再调 Rust 工具链打包。注意 Tauri 1 已经停止维护，别让 AI 给你生成 v1 的配置——v2 的配置文件结构变了（capabilities 权限模型是 v2 的），混用直接报错。

第一次构建大概率会遇到两个经典报错，提前知道就不慌：Tauri 报 Rust 工具链缺失——装 rustup，Windows 上还要补 Visual Studio Build Tools（只装构建工具，不用装整个 VS）；Electron 打包后打开白屏——99% 是 main 入口的路径问题，开发时走的是 dev server，生产包里是 file:// 相对路径，loadFile 的参数别写绝对路径。这两个坑踩过去，后面就是重复劳动。

AI 生成配置时的 3 个必查点（vibe workflow 里 80% 的打包翻车都来自这三处）：第一，identifier / appId 有没有换掉占位符——AI 最爱留 com.example.myapp，而 Tauri 的 identifier 还是自动更新通道的身份标识，中途改名等于断掉所有老用户的更新。第二，files 白名单有没有把不该进的东西打进去——AI 常写 "files": ["**/*"]，把 .env、私钥、测试 fixture 全打进安装包；构建完跑一遍 npx asar list 看看包里到底有什么。第三，版本号有没有三处对齐——package.json、tauri.conf.json、Cargo.toml（Tauri 项目）必须同一个版本，updater 靠它判断"有没有新版本"，错一位更新逻辑就乱。建议在 CI 里加一步校验脚本，对不上直接 fail，比事后排查便宜得多。

四、自动更新实战：签名是绕不开的坎

没有自动更新的桌面应用，每发一版就要在群里喊"大家去官网重新下载"。更新机制本身不难，难的是它前面的签名。

electron-updater 是 electron-builder 的亲兄弟：package.json 里配 publish.provider: "github"，构建时自动生成 latest.yml 清单传到 GitHub Releases。客户端启动时检查清单，有新版就后台下载——靠 blockmap 做差分更新，只下载改动过的数据块，一个 150MB 的应用，小版本更新可能只下几 MB。灰度用 stagingPercentage：先推 10% 用户，观察崩溃率没问题再全量。这套是桌面端最成熟的更新方案。

Tauri updater 走另一套信任模型：tauri signer generate 生成 minisign 密钥对，公钥写进 tauri.conf.json，私钥存成 GitHub Secret（TAURI_SIGNING_PRIVATE_KEY）。每次构建产出安装包的同时产出 .sig 签名文件和 latest.json 清单。客户端更新前先验签，签名对不上静默拒绝——注意是"静默"，验签失败不会弹窗报错，只是不更新，排查时先查签名链。

签名成本（2026 年口径，一人团队预算表）。macOS：Apple Developer Program $99/年，没有免费路线——没签名的 dmg 在 macOS 上 Gatekeeper 直接拦截，"已损坏、移到废纸篓"是用户看到的原话。流程是 Developer ID Application 证书签名 → notarytool 提交公证（需要 Apple ID 专用密码或 App Store Connect API Key）→ stapler 装订票据，三步缺一不可。Windows：最省事的是 Azure Artifact Signing（原名 Trusted Signing）$9.99/月 Basic 版，密钥在微软的 HSM 里，CI 里直接调，不用买硬件；传统路线是 OV 证书约 $200–400/年、EV 约 $300–700/年——但 2023 年 6 月起私钥必须放在 FIPS 硬件 token 或云 HSM 里，"下载个 pfx 文件"已经不存在了，CI 里插 token 是噩梦；另外 2026 年 3 月起 CA/B 论坛把证书最长有效期砍到 460 天，续期比以前更频繁。Linux：GPG 签名免费，可选做。

macOS 公证的具体三步，本地跑通一次就记住了：xcrun notarytool submit MyApp.dmg --apple-id you@example.com --password <专用密码> --team-id TEAMID --wait 提交排队（通常几分钟到半小时），通过后 xcrun stapler staple MyApp.dmg 把票据"订"进安装包。专用密码在 appleid.apple.com 生成，别用登录密码；CI 里把它和证书 p12 一起存成 secret，workflow 里先 security import 证书再签名——这套流程第一次配要一下午，配好后就是全自动。

再说个扎心的真相：签名不等于免弹窗。Windows 的 SmartScreen 是"声誉制"——新证书、新应用，前几百次下载照样弹蓝框警告，靠下载量慢慢养出声誉；EV 证书历史上起步快一些，但 2024 年之后也不再是免死金牌。一人团队预算有限时的务实组合：Azure 签名（$9.99/月）+ 官网下载页写清楚"首次运行请点'更多信息 → 仍要运行'"，把解释成本前置，别让用户在蓝框面前自己猜。

五、安装包瘦身：从 200MB 到 30MB 的 6 个手段

一个 Vite + React 的 Electron 应用，不做任何优化打出来约 180–220MB。下面 6 个手段按投入产出比排序：

1. files 白名单 + asar 压缩。只打 dist/，排除 .map、README、测试 fixture。asar 本身带压缩，这一步约省 30–40%，是性价比之王。

2. 按平台分包。--mac、--win、--linux 分开构建，别把三平台的原生模块全塞进一个包。AI 生成的配置常忘记这点，一个"通用包"里躺着 mac 和 win 两套二进制。

3. dependencies 大扫除。devDependencies 本来不会进包，但 AI 常把构建工具、测试库写进 dependencies；monaco-editor、ffmpeg.wasm 这类巨无霸，能按需加载就别打包，能放 CDN 就别进安装包。

4. 大资源外置。模型文件、视频素材、字体包扔 CDN，首次启动按需下载；安装包只留壳。这是"从 60MB 到 15MB"的关键一跃，代价是首次启动多一次下载——对工具类应用完全可接受。

5. 换架构（激进但彻底）。Electron 的 150MB 是 Chromium 的体重，不是你的代码的体重。换 Tauri 直接掉到个位数 MB——这是架构级差距，靠优化追不上。包体积是生死线时，别在优化上雕花，直接换跑道。

6. 把差分更新当瘦身用。electron-updater 的 blockmap 差分让"更新包"只有几 MB。用户感知的"大"，一半来自首次下载，一半来自每次更新；更新包小了，用户对体积的抱怨少一半。

量化一下这条路：未优化 200MB → 白名单+asar 约 120MB → 剔巨无霸依赖+资源外置约 40–60MB → 换 Tauri 架构约 8–15MB。每一档都是真实项目的实测区间，不是理论值。举个具体的：一个内置代码编辑器的笔记应用，把 monaco-editor 从打包改成按需加载的 CDN 版本，安装包从 96MB 直接掉到 41MB，改动只删了三行配置——瘦身的第一性原理永远是"别把用户可能用不到的东西塞进包里"。

六、跨平台 CI 打包：一次打 tag，三个包

核心认知只有一句：不能交叉编译。Tauri 的 WebView 是各系统的原生库，mac 的 dmg 必须在 mac runner 上打，Windows 的 nsis 必须在 Windows runner 上打。所以标准姿势是 GitHub Actions 的 matrix——三个平台各跑各的：

jobs:
  publish-tauri:
    permissions:
      contents: write
    strategy:
      fail-fast: false
      matrix:
        include:
          - platform: 'macos-latest'
            args: '--target aarch64-apple-darwin'
          - platform: 'macos-latest'
            args: '--target x86_64-apple-darwin'
          - platform: 'ubuntu-22.04'
            args: ''
          - platform: 'windows-latest'
            args: ''
    runs-on: ${{ matrix.platform }}
    steps:
      - uses: actions/checkout@v4
      - uses: tauri-apps/tauri-action@v0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}

三个平台差异点：Linux runner 要先 apt install 装 WebKitGTK 等系统依赖——注意 Tauri 2 要的是 libwebkit2gtk-4.1-dev，v1 时代的 4.0 装了也编不过；mac 想出 universal 包就用上面的双 target 写法；Electron 路线则是 electron-builder --publish always，mac 签名把证书 p12 和密码存成 secret 传 CSC_* 环境变量。

触发方式用 push.tags: v*——打 tag 即发版。产物命名定死规范：MyApp-1.2.3-mac-arm64.dmg、MyApp-Setup-1.2.3-win-x64.exe、myapp_1.2.3_amd64.deb，平台、架构、版本号都在文件名里，用户下错包的概率归零。Release 设成 draft，先下载验证一遍再点 publish——验证清单就三项：全新安装能跑、从上一版自动更新能升上来、签名信息里的发布者名字是对的。最后是版本号铁律：git tag = package.json = tauri.conf.json = Cargo.toml，四处对齐，CI 第一步就校验，对不上直接 fail——别等到用户收不到更新才发现版本号写劈叉了。

七、分发与上架：官网直发 vs 商店

包打出来了，给用户的方式有三条路，取舍很现实：

官网直发：0 抽成、更新随时发、安装包形态自己定。代价是签名自己搞、流量自己买、信任自己攒——用户第一次下载看到 SmartScreen 蓝框，解释成本你出。这是 90% vibe 项目的起点，也是终点。

Mac App Store：抽成 15–30%、审核 1–2 天一轮、每次更新走审核。换来的是用户信任、商店搜索流量、苹果替你管支付。隐性成本是沙盒：entitlements 按最小权限批，全局快捷键、开机自启这类能力在沙盒里要么受限要么做不到——第一节里让你打包的那 5 个场景，有一半在 MAS 里要打折。如果你做的恰恰是系统级小工具，MAS 可能根本装不下你的产品形态。

Microsoft Store：开发者账号一次性 $19，抽成约 15%，MSIX 包由微软替你签名——等于花 $19 买断了 SmartScreen 弹窗问题。代价是国内用户几乎不用微软商店，以及 MSIX 的安装形态和你官网的 exe 是两套东西。

一人团队的推荐路径：先官网直发 + GitHub Releases 跑起来，验证"有人愿意下载安装"这件事；有稳定付费用户、更新节奏固定后，再评估 MAS——苹果用户付费意愿高，30% 的抽成在"有人付费"的前提下才值得交。另外别忘了免费的中间路线：winget（Windows 包管理器）接受未签名的安装包（配 SHA-256 pin 即可），技术用户装机第一件事就是 winget install；Snap Store 覆盖 Linux 桌面用户。这两条都不花钱，适合冷启动期。

最后一句：打包是把"我的电脑能跑"变成"所有人的电脑能装"的最后一公里。它不性感，全是脏活——证书续期、公证排队、版本号对齐、SmartScreen 声誉。但当你看到更新推送出去、用户什么都不用做就用上新版时，会觉得这套脏活值了。先从一个能双击安装的 .dmg 开始，剩下的交给 CI——祝你的第一个安装包一次装上。