「写个桌面应用」这件事，2026 年有四条主流路线：Electron、Tauri、Wails、MyGo。名字都听过，但很多人说不清它们到底差在哪——毕竟用起来都能「写代码 → 得到一个 .app/.exe」，语法差异谁都能查表。
这篇文章不讲语法。真正的分界线只有一个：你的界面到底跑在哪、由谁画。 这一个问题的答案，决定了包体大小、内存占用、团队技能要求，以及你会掉进哪些坑。文中所有版本号和数据都在 2026-11-08 从各项目官方发布页核实过，不是凭印象写的。
四个框架，一张底表
| Electron | Tauri | Wails | MyGo | |
|---|---|---|---|---|
| 项目创建 | 2013 | 2019 | 2018 | 2026-09 |
| GitHub Stars | 12.4 万 | 11.3 万 | 3.7 万 | 5.3 千 |
| 当前版本 | v45.2.3 | v2.12.5 稳定（v3 alpha 推进中） | v3.0.0（2026-10-26 刚正式） | v0.8.3 |
| 后端语言 | JavaScript / TypeScript | Rust | Go | Go |
| 界面跑在哪 | 自带的 Chromium | 系统 WebView | 系统 WebView | 系统 WebView 或 GPU 自绘 |
| 打包体积 | 打包一整个浏览器 | 零浏览器依赖 | 零浏览器依赖 | 零浏览器依赖 |
| 成熟度 | 十三年，生态最厚 | 生态完善 | 八年，v3 重写刚落地 | 六周，API 未冻结 |
表格里最扎眼的不是数据本身，而是 MyGo 那一列——一个只存在了六周的项目，凭什么和三个八年以上的老项目放一张表里？往下看。
一条主线：界面跑在哪，由谁画
四个框架可以摆在同一条谱系上，从「最重的浏览器」到「最轻的自绘」，越往右对系统已有的东西依赖越少：
三个 Web 系框架（Electron、Tauri、Wails，以及 MyGo 的 Web 模式）共享同一个逻辑：复用你已有的 Web 技能——把你已经写好的前端代码装进一个桌面窗口。它们之间的差别是工程细节，不是范式差异。
MyGo 的原生 UI 模式是另一条路：用 Go 写界面、GPU 直接绘制，每个像素都由你的程序自己画，不借浏览器，也不实例化系统 WebView。（我实测跑过，后面有数据。）
所以「哪个框架开发快」是个伪问题：Web 派的快，是复用你已会的 HTML/CSS/JS；Go 派的快，是复用你已会的语言和已有 Go 代码。只存在对「你」的快，不存在绝对的快。
分框架细看
Electron：最重，也最省心
Electron 的选择逻辑十三年没变过：用一整个 Chromium 换「所有用户看到的东西完全一致」。Windows 用户跑的和你 Mac 上跑的是同一个浏览器内核，Safari 的怪癖、各发行版 WebView 的差异，统统与你无关。VS Code、Slack、Discord 都是它。
- 选它：团队是前端；界面复杂或强依赖 Web 生态（Monaco 编辑器、WebGL、成熟的组件库）；对包体和内存不敏感；需要最成熟的自动更新、崩溃上报、打包分发体系——它是四个里生态最厚的。
- 别选它：安装包普遍 80–100MB 起步、空载内存数百 MB 是它的常态。如果你只是想要「一个带界面的本地工具」，为它打包一整个浏览器是巨大的浪费。当前稳定版 v45.2.x 内置 Chromium 156 与 Node 24.22，安全补丁跟进很勤，但「自带浏览器」这个根本设定不会变。
Tauri：包体和内存的两全解
Tauri 的核心设定：不打包浏览器，借用户系统里已有的 WebView（macOS 用 WKWebView，Windows 用 WebView2，Linux 用 WebKitGTK）。代价是渲染层不跨端一致——同一份 CSS 在 WKWebView 和 WebView2 里可能有细微差异，而 Linux 各发行版 WebKitGTK 版本参差，是社区里抱怨最多的点。
- 选它：前端是你的主场，但受不了 Electron 的包体；想要移动端——Tauri 2 自带稳定的 iOS / Android 支持（Wails v3 的移动端还在 alpha），这是它相对 Wails 的独占优势；Rust 后端的性能与安全边界也是加分项。
- 别选它：团队完全没接触过 Rust，纯粹为一个小工具上 Rust 有学习成本；对渲染一致性有像素级要求。
- 一个值得盯的动向：Tauri v3 的 alpha 里出现了官方 CEF 运行时（
tauri-runtime-cef，可选捆绑 Chromium）。如果最终落地，等于 Tauri 自己把「渲染一致性」这条短板补上了，届时它会同时覆盖自己和 Electron 的场景。
Wails：Go 开发者的 Web 壳
Wails 和 Tauri 一样借系统 WebView，差别在后端语言：Wails 用 Go，Tauri 用 Rust。它把 Go 的 HTTP、数据库、文件处理生态直接接进桌面壳，前后端通过自动生成的类型安全绑定通信。
就在两周前（2026-10-26），Wails v3.0.0 正式发布——这是一次彻底重写：新的 services 机制（Go 结构体自动生成 TS 绑定）、Windows MSIX 安装包、macOS DMG 与 App Store 分发、Linux 全家桶（AppImage / deb / rpm / Arch），以及可插拔的应用内更新器（支持 GitHub Releases 等源、密码学校验、原子交换带回滚）。11-01 又跟进了 v3.1.0。
- 选它：后端逻辑已经是 Go，或你想用 Go 写，同时界面想继续用 Web 技术栈。八年项目，社区稳定，API 稳定性可以按正式版预期。
- 别选它：后端不是 Go 也无意转 Go（那就 Tauri）；深度依赖 v2 老插件——v3 是重写，插件生态需要时间迁移。
MyGo：唯一不借浏览器画界面的
MyGo 是独立开发者 egoist 2026-09-26 开源的新框架，六周 5.3k stars，当前 v0.8.3。它有两种模式，第二种是四个框架里独有的：
- Web 模式：和其他三家的逻辑一样——系统 WebView 里跑前端，Go 后端通过自动生成的 TypeScript 客户端接收调用。
- 原生 UI 模式：用 Go 直接写界面，GPU 绘制，没有 HTML、没有 JS，也不实例化 WebView。文本渲染由 go-text/typesetting 处理，官方文档标注了主题、暗色模式、本地化与无障碍支持。
我把它跑起来了（macOS / arm64 实测）
上面这些不是文档转述——我在 macOS 26.5.2 / Apple Silicon 上把两种模式都真实编译、运行了一遍（Go 1.27.3，MyGo v0.8.3）：
| 实测项 | 结果 |
|---|---|
| 依赖里有没有 Wails | 没有。全模块 1777 个 .go 文件 grep “wails” 零命中，go list -m all 闭包零 wails —— 独立实现成立 |
| 是否真能免 cgo 构建 | 能。CGO_ENABLED=0 go build 成功，产出 14MB 二进制；模块内零 import "C" |
| 产物体积 | native-app.app 与 web-app.app 各 9.5MB（已签名，arm64） |
| 里面有没有浏览器 | 没有。otool -L 只有 libSystem / libresolv / CoreFoundation / Security 四项，无 Frameworks/ 目录、无 Chromium Helper |
| 原生模式真在自绘吗 | 是。Metal 渲染（CAMetalLayer + 自带 shader.metal）；对照实验：单独跑原生 app 零 WebKit 子进程，跑 web app 则新增 WebContent / GPU / Networking 三个 —— 原生模式确实没实例化 WKWebView |
| 前端拿到的 TS 绑定 | mygo generate 产出普通 src/mygo.ts（类型定义在 mygo-runtime 包的 dist/*.d.ts）；窗口里显示的 darwin/arm64 · go1.27.3 来自 Go 侧，时钟每秒由 Go 事件推到前端 |
三个必须说清的细节，否则就是误导：
- 「没有 HTML/JS/WebView」只对原生 UI 模式成立——Web 模式就是标准 WKWebView + HTML/JS。
- 准确说法是「不实例化 WebView」，不是「完全不碰 WebKit」：原生模式的进程里 WebKit.framework 仍被 dlopen 映射（无条件加载），只是没有创建 WKWebView 实例。谁去翻 vmmap 会看到这行。
- 需要 Go 1.27.3+：本机 1.27.2 直接跑 CLI 会失败，得让
GOTOOLCHAIN=auto自动切版本。 - 不要据此推断内存优势：这次实测原生 RSS 约 94MB、Web 模式约 98MB，差距很小；两个示例的应用包也同为 9.5MB。这只是一次样本，不代表所有应用的结果。
未覆盖的部分我直说：DMG 打包在我的机器上 hdiutil detach 报 exit 16（环境问题，用 --skip-dmg 拿到了 .app），Linux 与 Windows 没有实测，跨平台结论请以官方 CI 为准。
选它：你写 Go，想要「UI 也是 Go」的纯 Go 应用；UI 简单而逻辑重（设置面板、监控小工具、内部工具）；或对纯 Go 二进制交叉编译有执念。 别选它：它六周大、v0.8.x，官方文档明说 API 还会调整；生态零起步，没有组件市场，没有现成的复杂表格、编辑器组件；Web 模式的配套（更新器、分发流水线）也还在路上。
具体决策：MyGo 还是 Wails？
这是 Go 开发者最常纠结的一对——后端都是 Go，都能配 Web 前端，都零浏览器依赖。分界线其实很清晰：
| 问题 | 答「是」→ | 答「否」→ |
|---|---|---|
| UI 必须复用 Web 生态（组件库 / 图表库 / 编辑器）？ | Wails | 继续下一行 |
| 能接受六周大、API 未冻结的新项目？ | MyGo（或它的 Web 模式） | Wails |
| 需要开箱即用的自动更新 / 签名分发流水线？ | Wails | MyGo 可一试 |
| 想要「不写一行 HTML/JS」的纯 Go 应用？ | MyGo 原生模式 | Wails |
一句诚实的提醒：如果你的 UI 要复用前端生态，别用 MyGo 原生模式硬写——你省下的是一个 WebView，赔上的是整个 Web 生态。原生模式适合「UI 简单、逻辑在 Go、想零浏览器」的场景，不适合拿来硬画复杂 Web 级界面。
完整决策树
上手成本
- Electron：
npm create官方模板起步，前端团队几乎零学习成本。 - Tauri：会前端，再加 Rust 基础——多数人卡在 Rust 工具链而非语言本身；文档质量在四者中公认最好。
- Wails：会 Go 即可
wails3 init起步；官方文档覆盖多窗口、菜单、托盘、更新器与各平台分发。 - MyGo：Web 模式
bunx mygo-cli init my-app起步；原生模式go run github.com/egoist/mygo/cmd/mygo@latest init -template native my-app，进项目后用go tool mygo dev热更新开发，mygo doctor体检开发环境。文档出奇地完整，连自动化测试和 E2E 都写了。但记住：文档完整 ≠ 成熟，六周的项目意味着你踩的坑没有前人答案。
写在最后
四个框架没有绝对优劣，只有「界面跑在哪」这条主线上的四个位置：Electron 自带浏览器，Tauri 和 Wails 借系统 WebView，MyGo 原生模式自己画。
MyGo 的出现更像一个信号：WebView 依赖正在变成可选项。半年前，「桌面应用 = WebView + 一门后端语言」还是行业默认；现在，一个六周大的项目已经证明纯 Go 自绘 UI 可行。另一边，Tauri v3 alpha 里官方 CEF 运行时的出现，说明「借系统 WebView」这条路也在被重新审视——有人愿意为了渲染一致性主动捆绑浏览器。两个方向的演化都值得继续观察。
选型时先回答两个问题：① UI 是否复用 Web 技能和组件？② 能否接受新项目的未冻结风险？ 这两个答案会把四个框架放进各自的象限；剩下的差异——包体、内存、生态厚度——都是这两个问题的下游。
参考
版本与数据均于 2026-11-08 核实：
- Electron v45.0.0 Release Notes（Chromium 156 / Node 24.22）
- Tauri v2.12.5 · tauri-runtime-cef v3.0.0-alpha.7 · Tauri 2.0 Stable Release
- Wails v3.0.0 Released（2026-10-26）· Wails v3.1.0
- MyGo GitHub 仓库 · MyGo 文档
