做出来了，发不出去：vibe 项目的桌面应用分发实战

AI 写桌面应用已经快得离谱：一个晚上，从零到一个能跑的 Tauri 或 Electron 应用，界面、功能、打包全齐。但接下来发生的事，很多人没料到——你把安装包发给第一个真实用户，对方双击之后看到的不是你的应用，而是 macOS 的"已损坏，无法打开"，或者 Windows 的蓝色 SmartScreen 警告："Windows 已保护你的电脑，未识别的应用。"你熬夜调出来的功能，用户连看都没看到。

用户不会去研究什么叫代码签名，他只会得出一个结论：这软件有问题。然后删掉，再也不回来。你损失的不是一次下载，是一个原本愿意试用的种子用户——而种子用户是独立开发者最宝贵的资产。

这不是你的代码有问题，是分发这条跑道你还没铺。代码签名、Apple 公证、Windows 证书、自动更新、CI 打包——全是流程型脏活，AI 替你写不了配置、替你交不了年费、替你保管不了私钥，你得自己走一遍。好消息是：走通一次，后面全是复制粘贴。本文就是这条跑道的完整施工图：从选 Electron 还是 Tauri，到用户双击安装包的那一刻，再到他收到第一次自动更新。

先划个界：本文只管桌面端分发。移动端上架（App Store / Google Play 审核流程）和浏览器扩展上架是另一套玩法，VibeFix 另有《vibe-project-mobile-app-store-launch-guide》与《browser-extension-store-launch-guide》两篇指南覆盖，不在这里展开。

本文适合谁：已经用 AI 写出了能跑的桌面应用、卡在"怎么发给用户"这一步的独立开发者。不管你用的是 Electron 还是 Tauri，跑道是同一条，只是施工工具不同。跟着走一遍，大约需要一个周末：周六搞定签名和公证，周日接好自动更新和 CI。从下周一开始，你的发版就是一条命令的事。

一、先选跑道：Electron vs Tauri 决策表

分发成本很大程度上在选型那一刻就定了。包体积决定用户愿不愿意下载，启动速度决定用户愿不愿意留下来，这两件事在你 npm create 的那一刻就写好了结局。两个框架按四个维度打分，分数越高越适合独立开发者：

维度	Tauri (v2)	Electron
包体积	★★★★★ 安装包通常几 MB 到十几 MB，用系统 WebView，不打包浏览器内核	★★☆☆☆ 自带完整 Chromium，安装包动辄 100MB+，dmg 压完还大
启动速度与内存	★★★★★ Rust 二进制 + 原生 WebView，冷启动快、内存占用低	★★★☆☆ Chromium 启动开销大，常驻内存高，用户电脑风扇转起来会回来骂你
系统 API 覆盖	★★★☆☆ 官方插件体系已成熟（fs、dialog、updater、notification 等），但冷门系统能力可能要自己写 Rust	★★★★★ 十年生态，npm 上什么插件都有，Node API 全量可用，调系统能力基本不用碰原生代码
一人维护成本	★★★★☆ 要能读懂 Rust 编译报错，但日常开发还是前端那一套；构建链多一环（cargo）	★★★★★ 纯 JS/TS 心智负担最低，构建链就是 npm

结论很明确：默认选 Tauri。包体积和启动速度是桌面应用的用户体验生死线，独立开发者没有品牌溢价去让用户忍受 150MB 的下载和转圈的风扇。一个 8MB 的 dmg 和一个 150MB 的 dmg，用户点下载按钮时的心理完全是两回事。

VibeFix 上的 PaperOtter 就是典型样本：Tauri + Rust + TypeScript，一人维护，Mac / Windows / Linux 三端，本地文档工具箱，2026 年 9 月以来 775 个 commit 持续迭代，还自己做了启动时更新检查——这正是 Tauri 的甜点区：小而美、跨三端、一人可维护。

三种情况回 Electron，别硬扛：第一，应用重度依赖 Chromium 独有能力（比如内嵌 PDF 渲染、特殊音视频编解码、Widevine DRM），Tauri 的系统 WebView 给不了；第二，团队对 Rust 零意愿且工期极紧，Electron 的纯前端心智负担确实低；第三，目标用户有大量老旧或魔改系统（某些企业内网 Windows、魔改 Linux 发行版），Electron 自带 Chromium 的一致性反而更省心——Tauri 在 Linux 上依赖系统 webkit2gtk，发行版一杂就容易出幺蛾子。除此之外，别犹豫，选 Tauri。

选定之后先搞清楚你的构建产物长什么样，免得后面配更新源时对不上号：Tauri 在 macOS 上产出 .app 和 .dmg（updater 用的是 .app.tar.gz），Windows 上是 NSIS 的 .exe 和 MSI（updater 复用安装包本身），Linux 上是 AppImage / .deb / .rpm。Electron 那边，Squirrel.Windows 要 .nupkg，macOS 要 zip 或 dmg。更新源配置里的文件后缀必须和构建产物对上，这是第四章配 endpoint 时最常见的低级错误。

最后回应一个 vibe coder 最关心的问题：AI 写 Rust 行不行？行。Tauri 应用的 Rust 部分通常很薄——就是官方模板那几十行加上几个 command，AI 生成的质量足够用；真正复杂的业务逻辑还是在前端。出问题时把编译报错贴回去，AI 修 Rust 编译错误的能力其实比修 JS 逻辑 bug 更可靠，因为编译器把错指得明明白白。别因为"不会 Rust"就退回 Electron，那是用战术上的舒服换战略上的包袱。

二、macOS 双保险：Developer ID 签名 + 公证

macOS 的分发就八个字：先签名，再公证。缺一不可——只签名不公证，macOS 10.15+ 照样把你拦下来，Gatekeeper 可不认"签了一半"。

前置成本先说清楚：Apple Developer 会员，99 美元/年。这是拿签名证书和用公证服务的唯一入口，没有替代方案，也没有"个人免费版能凑合"的说法（免费账号只能真机调试，不能做 Developer ID 分发签名）。证书类型选 Developer ID Application（站外分发的），别选成 Apple Distribution（那是上架 Mac App Store 用的，选错后面全白干，还得重新走 CSR 流程）。

标准流程四步，每一步都有坑：

• 打包产物：先得到 .app 或 .dmg。注意 bundle 里每一个可执行文件、每一个 helper、每一个嵌套的 .app 都要签，漏一个，公证就挂。
• codesign 签名：用 Developer ID Application 证书签，记得开 hardened runtime、带时间戳。这一步漏了 hardened runtime，后面公证必被拒。Tauri 用户在 tauri.conf.json 里配 signingIdentity（或 APPLE_SIGNING_IDENTITY 环境变量），build 时自动签；本地没证书想先跑起来，可以用 "-" 做 ad-hoc 签名，但这只能自己玩，分发不了。
• notarytool 提交：xcrun notarytool submit --wait，Apple 做自动化安全扫描，通常几分钟到十几分钟出结果。注意：公证不是"审核上架"，它只是 Apple 的自动化恶意代码与签名检查，别拿 App Store 审核的心态去等它，也别在更新说明里写"已通过 Apple 审核"——那是两回事。
• stapler 装订：通过后用 xcrun stapler staple 把公证票据装订进产物。这样用户离线时 Gatekeeper 也能认可；不装订就得联网查票，多一分不确定性。分发 dmg 的话，把 dmg 本身也 staple 一遍。

Tauri 用户最省心：配好签名身份后，公证走 App Store Connect API（APPLE_API_ISSUER / APPLE_API_KEY / APPLE_API_KEY_PATH）或 Apple ID，tauri build 时自动走完签名→公证→装订全套。Electron 用户用 @electron/notarize 或 Electron Forge 的配置，思路一样，Electron 官方代码签名文档把 Forge、Packager、Builder 三条路都写清楚了。

一个 Electron 特有的坑，值得单独拎出来：safeStorage（钥匙串加密）、autoUpdater（Squirrel.Mac 自动更新）、setLoginItemSettings（开机自启）这些 API，没签好名会行为异常——钥匙串每次更新都重新弹授权、开机自启静默注册失败。看着像框架 bug，其实全是签名问题。Electron 官方文档把这一点专门列了出来：没签名的应用，macOS 认不出"两次构建的是同一个应用"。调试前先自查签名，能省一下午。

公证被拒别慌，九成是这三类原因：bundle 里混进了没签名的 helper 或第三方二进制（Electron 应用最常见，打包时顺手塞了个没签名的 ffmpeg 之类）；entitlements 写错或缺失；没开 hardened runtime。看 notarytool 的 log 逐条修，修完重提就行。第一次提交有时会慢一些，后面就快了。

两个实操细节：提交给公证的格式，dmg 和 zip 都可以，但注意是先签名再打包成 dmg、然后对 dmg 做公证和装订，顺序别反；排查时用 xcrun notarytool log 拉完整日志、xcrun notarytool history 看提交历史，比盯着 --wait 的输出干等管用。Tauri 的 CI 模板里如果公证反复失败，可以先加 --skip-stapling 跑一遍，确认签名本身没问题，再把装订加回来，分段排查。

三、Windows 签名：OV、EV 与云签名三条路

Windows 这边没有 Apple 式的统一公证，只有代码签名证书，逻辑是另一套：先给证书，再谈信任。没证书，你的应用在用户眼里就是"未知发布者"；有证书，SmartScreen 会根据你的"声誉"决定弹不弹警告。

先说结论：独立开发者先看 Azure Trusted Signing（现改名 Artifact Signing，微软官方云签名服务）。Basic 档 9.99 美元/月，每月 5000 次签名，Electron 官方文档原话是"这是 Windows 代码签名最便宜的选择"，而且"能消除 SmartScreen 警告"。私钥放在微软的 HSM 里，你只管调 API，不用买加密 U 盘，不用操心证书续期——证书有效期只有约 3 天，自动轮换，偷了也没用。Tauri 官方文档也给了接法：signCommand 配 artifact-signing-cli，把 endpoint、账号名、证书 profile 名填进去就行。

传统两条路长这样，选之前先看清代价：

• OV 证书（组织验证）：便宜，每年一百多美元起。但 SmartScreen 信任度要靠时间和下载量慢慢攒——新应用发布头几个月，用户照样会看到蓝色"未知发布者"警告框。适合不着急、靠口碑慢慢起量的工具。Tauri 官方文档的 Windows 签名指南就是以 OV 证书为主线写的：转成 .pfx、导进证书存储、配 certificateThumbprint，一步步都列出来了。
• EV 证书（扩展验证）：贵，每年 300–900 美元，但起步信任度高，SmartScreen 警告少得多。代价是：2023 年 6 月之后微软要求 EV 私钥必须放在符合 FIPS 140-2 的硬件安全模块里，不能下载到 CI 机器上。这对 GitHub Actions 自动化是致命伤——总不能每次发版都把 U 盘插到跑 CI 的电脑上。除非用云签名方案（比如 DigiCert KeyLocker，Electron 官方自己的应用就用这个），把硬件放在服务商机房、远程调用签名，否则你的流水线在"插 U 盘"这一步就卡死了。

证书从哪买？微软不直接卖，找 DigiCert、Sectigo、GlobalSign、SSL.com 这些 CA 或其代理，货比三家，价格差得不少。注意别买成 SSL 证书——那是给网站 HTTPS 用的，签不了代码，Tauri 官方文档里专门用感叹号强调了这一点，每年都有人踩。

还有一条野路子：如果你在 Linux 或 macOS 上开发，Electron 官方文档提到了 jsign，可以用它调 Azure Trusted Signing 给 Windows 程序签名，不用开 Windows 虚拟机。Tauri 这边则可以用 relic 配 Azure Key Vault。工具很多，核心都是同一件事：别让私钥离开安全的地方。

关于 SmartScreen 的"声誉"机制，多说一句：它本质上是个黑盒评分，下载量、时间、证书类型都在里面。OV 证书的新应用，前几百次下载大概率还是会弹警告，这是正常的，不要因此怀疑人生。加速积累声誉的正道是：尽早签名、尽早发布、保持更新频率，让"同一个发布者持续发布正常软件"这个信号稳定下来。EV 证书只是把起跑线往前挪了一大截，不是免死金牌——行为恶劣的软件，EV 一样会被吊销。

这一节最值得背下来的一句话：时间戳服务器必须配。证书会过期，时间戳（RFC 3161）证明的是"这个签名发生在证书有效期内"。配了时间戳，证书过期后你的历史版本依然被信任；没配，证书一到期，所有老版本一夜之间全变"未知发布者"。Tauri 配置里的 timestampUrl、signtool 的 /tr 参数，都是干这个的。别等到第一张证书过期那天才想起来——那天你会在用户群里解释一整天。

算一笔总账：Apple Developer 99 美元/年 + Azure Trusted Signing 9.99 美元/月，一年 220 美元左右，这是"双端可信分发"的入场券。OV 路线一年一百多美元但要忍几个月的 SmartScreen 警告，EV 路线一年 300–900 美元但要解决 HSM 进 CI 的问题。独立开发者按这个顺序试：Azure Trusted Signing → OV → EV，基本不会错。

四、自动更新二选一：electron-updater vs Tauri updater

分发出去了只是上半场。用户装的是 1.0.0，你修了个 bug 发 1.0.1，指望用户手动下载重装？别做梦了。自动更新不是加分项，是分发的一部分，第一天就要接好。等用户量起来了再加，迁移成本和客服成本会教你做人——老版本没有更新客户端，你连推送都推不出去。

• electron-updater（基于 Squirrel）：生态最成熟，GitHub Releases 直接做更新源，配置几行搞定，断点续传、差分更新都是现成的。注意 macOS 端 Squirrel.Mac 要求应用必须已签名才能工作——又回到第二章，签名是地基，地基不牢，更新都跑不起来。
• Tauri updater 插件：核心是 minisign 密钥对。tauri signer generate 生成 .key（私钥）和 .key.pub（公钥，内容写进 tauri.conf.json，注意是内容不是文件路径）；CI 里通过 TAURI_SIGNING_PRIVATE_KEY（和 TAURI_SIGNING_PRIVATE_KEY_PASSWORD）环境变量签名——官方文档明确说了，.env 文件在这里不生效，必须用真正的环境变量；createUpdaterArtifacts 设为 true，构建时自动生成带 .sig 签名的更新包和 latest.json 清单，endpoints 指向 GitHub Releases 的 latest.json，tauri-action 会自动把它上传到 Release 里。Windows 上还有个 installMode 可以选 passive（进度条、无需交互，推荐）还是 quiet。

红线来了，听好：updater 私钥丢了，你就永远失去了给已安装用户推送更新的能力。Tauri 官方文档的原话是：永远不要和任何人分享私钥；如果丢了它，你将没法再向已安装的老用户发布更新。到时候唯一的办法是发公告求用户手动下载重装——对独立开发者这是灾难。所以：私钥进密码管理器，异地再备一份，这是基础设施级别的事，别存在某台笔记本的 ~/.tauri 里就完了。轮换电脑、重装系统前，先确认私钥有备份。

权限别忘了配：Tauri v2 的能力模型要求在 capabilities 里显式声明 updater:default、updater:allow-check、updater:allow-download-and-install 等权限，不声明，前端调更新 API 会直接被拒。这是 v2 安全模型的一部分，不是 bug。

进阶玩法：Tauri 的 endpoints 支持 {{target}} / {{arch}} / {{current_version}} 变量，服务端可以按版本做灰度、做回滚，甚至可以在运行时动态切换 endpoint——beta 通道隔离就靠这个，第七章展开。

更新的交互设计也值得花心思。推荐的组合是：启动时静默检查一次（别弹窗打断），菜单栏 / 设置页里放一个"检查更新"手动入口，有更新时弹一个带更新说明的对话框让用户选"立即更新"或"稍后"。Tauri updater 插件默认带 dialog，也可以关掉自己接事件做进度条。千万别学某些软件：后台偷偷下载、关闭时强制安装、重启后还丢配置——每一次粗暴的更新，都是在消耗用户对"自动更新"这四个字的信任。

五、分发渠道四选一：成本与信任度对比

包签好了、更新接好了，用户从哪拿到第一个安装包？四个渠道，按成本和信任度排个序。注意这四个不是单选题，是组合题：

渠道	成本	信任度	适合谁
官网直分发	一个域名 + 对象存储	全靠你的签名和公证撑着；页面做得丑，信任度直接打折	有品牌、要做落地页的产品
GitHub Releases	零	开发者信任度高；普通用户看到 github.com 链接会犹豫	开源项目、开发者工具；天然就是更新源，一鱼两吃
Homebrew cask	零（自己维护 tap，一行 formula）	Mac 开发者信任度拉满，一行命令安装	独立开发者的信任杠杆
winget / MSIX	winget 免费（提 PR 上架）；MSIX 打包配置繁琐	Windows 用户信任度高；MSIX 适合进企业采购清单	要覆盖普通 Windows 用户 / 企业客户

真实样本：VibeFix 上的 whrss，独立开发者用 AI 一周"蹬"出四个 Swift 菜单栏小工具，全部走完 Apple Developer ID 签名与公证，下载解压双击就能用，各应用自己检查 GitHub Releases 更新，安装方式是一行 brew install --cask whrss9527/tap/pop。签名公证解决"能打开"，Homebrew 解决"敢装"，GitHub Releases 解决"有更新"——三件套齐了，一人团队也能做出大厂的分发体验。

Homebrew cask 值得多说两句：对 Mac 开发者，它是信任度最高的零成本渠道。你不需要过任何审核，自己维护一个 tap 仓库，把 cask 文件指向你的 GitHub Releases 产物就行。用户 brew install --cask 一行搞定，比去官网找下载按钮的体验好得多。winget 同理，给 winget-pkgs 提个 PR，Windows 用户 winget install 就能装上。官网落地页则做好一件事：自动识别访客系统，把对的下载按钮怼到他脸上——让 Mac 用户去找 .exe 的官网，每年都在劝退一批人。

我的建议：独立开发者起手式是 GitHub Releases（更新源）+ Homebrew cask（Mac 获客）+ winget（Windows 获客）+ 官网落地页（收拢品牌）。四个全要，总成本几乎为零，信任度互相加成。官网是门面，剩下三个是水管。

一个容易忽略的互斥关系：如果你打算上架 Mac App Store 或 Microsoft Store，就别再自己搞自动更新了——商店政策禁止应用自更新，Tauri 官方文档里明确写了 updater 插件在移动端和商店渠道下受限。站外分发和商店上架是两条路线，选了一条就把另一条的配套设施配齐，不要混搭。

六、CI 打包流水线：一次配好，终身发版

手动打包发版，第三次你就会烦，第十次你就会出错，第二十次你就会漏签某个平台。GitHub Actions 三平台矩阵是标准答案，一次配好，终身受益：

• 矩阵：macos-latest（arm64 和 x86_64 两个 target，Tauri 官方模板就是这么写的）、ubuntu-22.04、windows-latest；fail-fast: false，一个平台挂了别拖死另外两个。注意 Linux 构建要先装 webkit2gtk 等系统依赖，Tauri 官方模板里有现成的 apt 命令，抄就行。
• 密钥进 Secrets：APPLE_CERTIFICATE（base64 后的 .p12）、APPLE_CERTIFICATE_PASSWORD、TAURI_SIGNING_PRIVATE_KEY、WINDOWS_CERTIFICATE 等。workflow 里只引用 ${{ secrets.XXX }}，永远不要 echo 出来，日志里露一次就得吊销重办。另外记得给 workflow 开 contents: write 权限，否则 tauri-action 创建 Release 时会报 "Resource not accessible by integration"，这是官方指南里专门列出来的坑。
• tauri-action：官方维护的 Action，一行调用完成 tauri build、产物上传、GitHub Release 创建。Tauri 官方分发指南给了可直接复制的 workflow 模板：checkout → 装 Node → 装 Rust（带 swatinem/rust-cache 缓存，构建能快一倍）→ 装前端依赖 → tauri-apps/tauri-action@v1。触发方式建议用 tag 推送（app-v* 或 v*），发版就是 git tag v1.2.0 && git push --tags，然后等 20 分钟收 Release。

Electron 用户走 Electron Forge / electron-builder，思路完全一样：矩阵构建 → 签名（@electron/windows-sign / @electron/osx-sign）→ 公证（@electron/notarize）→ 上传 Release。工具不同，跑道同一条。Electron 官方代码签名文档把 Forge、Packager、Builder、Squirrel.Windows、WiX MSI 每一家的接法都列了，对号入座就行。

仪式感建议：第一次跑通流水线的那天，把推送 tag 的那个瞬间留给自己。从这天起，发版不再是"一个一下午的体力活"，而是一条命令。你的 vibe 项目从此有了工业级的发版能力，而你只是一个人。

流水线跑通之后，下一步是把它做"傻瓜化"：写一个发版脚本，一键做三件事——按 semver bump 三处版本号（tag、tauri.conf.json、package.json，三处不一致是更新检查失效的常见原因）、从 git log 生成 changelog 草稿、打 tag 推上去触发流水线。Tauri 官方模板里还有个贴心设计：releaseDraft: true，先以草稿形式创建 Release，你检查一遍产物没问题再手动点发布。新手期强烈建议打开它，等你对流水线完全放心了再关。

七、版本号与更新通道：发版的社会契约

自动更新面前，版本号就是你和用户的契约，乱来会付出代价。用户把"自动更新"的权力交给你，你就要对每一次推送负责。

先讲一个真实世界的教训：很多独立开发者第一次发版时，版本号随手写，1.0 发完直接跳 2.0，或者 beta 版和正式版混用同一个更新源。结果是用户某天一觉醒来，界面全变了，插件全挂了——因为 MAJOR 升级本该是用户主动选择的事。semver 不是形式主义，它是你在替用户做决定时的自我约束。

• semver 守规矩：MAJOR.MINOR.PATCH。破坏性变更必须升 MAJOR，别在 PATCH 里偷偷改快捷键、删功能——自动更新的用户没有"阅读更新说明再决定装不装"的机会，你替他做了决定，就要对后果负责。桌面应用尤其如此，因为回滚比网页难得多。
• beta 通道隔离：stable 和 beta 用不同的更新 endpoint。Tauri 的动态 endpoint 天然支持按 {{current_version}} 分流，服务端想给谁推就给谁推；electron-updater 也有 channel 配置。铁律：beta 用户永远收不到 stable 推送，stable 用户永远收不到 beta 推送。想让用户切通道，给个显式开关，别偷偷切。Tauri 的 updater 甚至支持运行时动态改 endpoint 和公钥，做灰度发布、金丝雀发布都够用。
• 强制更新只用在一种情况：安全漏洞。平时用"提醒 + 稍后"（Tauri updater 的 dialog 或自研弹窗），把选择权留给用户；静默安装、启动即装这种强制手段，留给企业内部分发。消费级产品强制更新一次，差评区就会多一条"更新完我的配置全没了"——这不是危言耸听，是这类产品的差评区常见标题。更新前备份用户数据，更新后验证配置还在，这是基本功。
• 更新文案写人话：latest.json 的 notes、Release notes，"修复了导出 PDF 时中文乱码"比"bug fixes and improvements"更能留住用户。写两句人话的成本是零，效果是用户愿意点"立即更新"而不是"稍后提醒我"。每次发版花五分钟写更新说明，是回报率最高的工作。

八、发版前 12 项检查清单

打印出来（或存成仓库里的 CHECKLIST.md），每次发版逐项打勾。别嫌烦，漏一项，代价都是用户流失。建议把这份清单也放进 CI：能自动化的检查（签名验证、版本号一致性、更新包签名校验）写成 workflow 的 job，机器比人可靠；只留下必须人肉点的几项（干净环境实测、更新文案），发版日花半小时走完。

• 1. 三平台安装包在干净虚拟机 / 新用户账号上双击能装、能启动（别在自己的开发机上测，那台机器什么证书都有，测不出问题）
• 2. macOS：spctl -a -vvv 验证 Gatekeeper 放行；stapler validate 确认票据已装订
• 3. Windows：在没装过你证书的机器上确认 SmartScreen 显示的是"已验证的发布者"而非"未知"
• 4. 签名带了时间戳（证书过期后历史版本依然可信——第三章那句话，检查一遍）
• 5. 自动更新：从上一个正式版升级到当前候选版，走一遍完整流程（下载、校验、安装、重启）
• 6. 更新签名验证：篡改一个字节的更新包，确认客户端拒绝安装（别让更新通道变成攻击入口）
• 7. 版本号符合 semver，且 tag、tauri.conf.json、package.json 三处一致
• 8. beta 通道与 stable 通道隔离验证（互相收不到对方的包）
• 9. 更新文案写了人话（Release notes 非空，不是"bug fixes"）
• 10. 回滚预案：如果新版有严重 bug，能否发更高版本号的修复版（降级不被允许时）；Tauri 动态更新服务器支持服务端直接下发回滚
• 11. 官网下载页 / Homebrew cask / winget 的链接指向的是新 Release（别让用户下到旧版）
• 12. 发版公告写好：更新内容、已知问题、反馈渠道（用户遇到问题知道去哪找你，比问题本身更重要）

最后再说一遍这篇指南的核心判断：默认选 Tauri，时间戳必须配，updater 私钥当基础设施保管，渠道四个全要。分发这条跑道没有银弹，但走通一次之后，你的每一个 vibe 项目就都有了一条从"做出来"到"发出去"的路。下一次 AI 一晚上写完应用，你 push 一个 tag，20 分钟后用户就能收到更新——这才是 vibe coding 该有的终点。

跑道铺好不是一劳永逸，每年还有两次"年检"：Apple Developer 会员续费（过期了证书和公证一起停摆，提前一个月设提醒），以及 Windows 证书或签名服务的续费。把这两个日期写进日历，和域名续费放在一起。分发能力就像水电，平时感觉不到，断一次就知道疼——而修起来往往要好几天。