如果你想用 Web 技术写桌面应用，大概率绕不开 Electron。
VS Code、Slack、Discord、Notion 这类产品，都让 Electron 证明了一件事：用 HTML、CSS、JavaScript 做桌面应用是可行的，而且能做得很复杂。
但 Electron 也有一个老问题：重。
一个简单的小工具，打包出来可能就是上百 MB；启动一个桌面应用，背后跑着 Chromium 和 Node.js。对于大型产品来说，这个代价可以接受，但如果只是做一个内部工具、效率工具、本地客户端，就会显得有点“大炮打蚊子”。
这也是我最近关注 Wails 的原因。
Wails 的思路很直接：用 Go 写后端逻辑，用前端技术写界面，然后通过系统 WebView 渲染 UI。
也就是说，它没有像 Electron 那样把 Chromium 和 Node.js 一起打进应用里，而是尽量利用操作系统自带的 WebView。后端则是一个正常的 Go 程序。
这让 Wails 很适合 Go 开发者。
一句话区别
如果只用一句话概括：
Electron 是“前端开发者把 Web 应用搬到桌面”；Wails 是“Go 开发者给自己的程序加一个现代前端界面”。
两者都可以做跨平台桌面应用，但出发点不太一样。
Electron 的核心是 JavaScript、Node.js 和 Chromium。它把 Web 运行时带到桌面端，所以你可以获得非常稳定、统一的渲染环境。
Wails 的核心是 Go 和系统 WebView。它更像是让 Go 程序拥有一个漂亮的前端界面，同时保留 Go 在性能、并发、工程化和单文件分发上的优势。
运行机制对比
先看最核心的区别。
| 对比项 | Wails | Electron |
|---|---|---|
| 后端语言 | Go | Node.js |
| 前端技术 | HTML / CSS / JS / Vue / React 等 | HTML / CSS / JS / Vue / React 等 |
| 渲染方式 | 系统 WebView | 内置 Chromium |
| 是否内置浏览器 | 不内置完整浏览器 | 内置 Chromium |
| 应用体积 | 通常更小 | 通常更大 |
| 系统能力调用 | 通过 Go 调用 | 通过 Node.js / Electron API 调用 |
| 适合人群 | Go 开发者、后端开发者、工具类应用开发者 | 前端团队、复杂桌面产品团队 |
| 成熟度 | 还在快速发展 | 非常成熟 |
Electron 的优势在于：它自带 Chromium，所以不同系统上的渲染表现更一致。你写出来的界面，在 Windows、macOS、Linux 上通常差异更小。
Wails 的优势在于：它不打包完整浏览器，应用更轻，后端是 Go，写系统工具、网络工具、本地客户端会很舒服。
但代价是：Wails 依赖系统 WebView，不同系统环境下的表现可能需要更多测试。
包体积：Wails 更轻
Electron 经常被吐槽的一个点就是包体积。
哪怕你只是写一个很简单的窗口应用，Electron 也需要带上 Chromium 和 Node.js 相关运行时。这样做的好处是环境统一，坏处是应用会比较大。
Wails 不走这个路线。
它使用系统 WebView 渲染前端界面，Go 代码编译成原生程序，所以通常打包体积会小很多。
这对于一些小工具非常有吸引力，比如：
- JSON 格式化工具
- API 调试工具
- 文件批处理工具
- 日志查看器
- 数据库管理小工具
- 内部运维桌面工具
这些应用本身逻辑不复杂，也不需要完整浏览器能力。用 Electron 当然能做，但可能显得太重。Wails 在这种场景下会更合适。
wails打包体积
electron包体积
开发体验：前端仍然熟悉，后端变成 Go
Wails 很有意思的一点是，它没有要求你放弃前端生态。
你依然可以用 Vue、React、Svelte 这些框架来写界面。前端负责页面和交互，Go 负责本地能力、业务逻辑、文件读写、网络请求、数据处理。
大概可以理解成：
前端页面：负责展示和交互
Go 后端：负责真正干活
Wails：负责把两边连接起来
对于 Go 开发者来说，这种模式很自然。
以前你写一个命令行工具，用户可能需要打开终端执行命令。现在你可以用 Wails 给它套一个桌面界面，让普通用户也能点点按钮完成操作。
这就是 Wails 最吸引我的地方：它不是让你从零学习桌面开发，而是把 Go 项目自然延伸到了桌面端。
Electron 的优势依然很明显
不过，Wails 并不是 Electron 的全面替代品。
Electron 发展了很多年，生态非常成熟。窗口管理、菜单、托盘、自动更新、插件体系、调试工具、社区案例，都比 Wails 更丰富。
如果你要做的是一个复杂商业桌面应用，Electron 仍然很稳。
比如：
- 类似 VS Code 的复杂编辑器
- 大量依赖 Node.js 生态的应用
- 对浏览器能力要求很高的产品
- 需要成熟自动更新和插件机制的桌面端
- 前端团队主导的大型跨平台客户端
这些场景下，Electron 的成熟度和生态优势会非常明显。
它重，但它稳定；它包体积大，但它能力完整。
所以不要简单说“Wails 替代 Electron”。更准确的说法应该是：
Wails 给 Go 开发者提供了另一条桌面应用路线。
Wails 更适合什么场景？
我觉得 Wails 特别适合下面几类应用。
第一类是内部工具。
很多公司内部都有一些脚本、运维工具、数据处理工具。原来可能是命令行，或者是一个简单 Web 页面。用 Wails 包成桌面应用之后，分发和使用都会更方便。
第二类是开发者工具。
比如接口调试、日志分析、配置生成、代码片段管理、数据库辅助工具。这类应用对性能和本地能力有要求，但界面又不需要复杂到 Electron 那种级别。
第三类是 Go 项目的 GUI 外壳。
如果你已经有一个 Go 写的核心程序，比如同步工具、代理工具、扫描工具、文件处理工具，那 Wails 很适合给它加一层桌面界面。
第四类是轻量跨平台客户端。
如果你希望应用尽量轻，不想为了一个小工具带上完整 Chromium，Wails 会很有吸引力。
什么时候继续选 Electron？
如果你的团队主要是前端开发者，Electron 仍然是更顺手的选择。
它的开发模型更贴近前端，相关资料更多，坑也更容易搜到。对于复杂桌面产品来说，Electron 的生态和工程实践更加成熟。
尤其是当你的应用需要大量使用 Node.js 生态时，Electron 的优势会很明显。
比如你要处理复杂插件、嵌入浏览器能力、做大型编辑器，或者希望不同平台的渲染环境尽可能一致，那么 Electron 依然是非常强的方案。
怎么选？
我的建议是：
| 你的情况 | 推荐选择 |
|---|---|
| 你是 Go 开发者 | 优先试试 Wails |
| 你想做轻量工具 | 优先试试 Wails |
| 你已有 Go 核心逻辑 | Wails 很适合 |
| 你是纯前端团队 | Electron 更顺手 |
| 你要做复杂商业客户端 | Electron 更稳 |
| 你依赖大量 Node.js 能力 | Electron 更合适 |
| 你在意包体积和资源占用 | Wails 更值得看 |
如果用一句更实际的话总结：
做轻量工具、内部系统、Go 项目 GUI，选 Wails；做复杂桌面产品、前端主导的大型客户端，选 Electron。
我的结论
Wails 最打动我的地方，不是它“打败了 Electron”，而是它让 Go 开发者多了一种选择。
以前 Go 很适合写服务端、命令行工具、网络程序、系统工具，但一到桌面界面，就容易尴尬。传统 GUI 框架学习成本不低，纯 Web 又不像真正的桌面应用。
Wails 正好补上了这块空白。
它让我们可以继续用 Go 写核心逻辑，再用熟悉的前端技术做界面。对于很多中小型桌面应用来说，这个组合已经足够舒服。
Electron 仍然是成熟、强大、生态完整的桌面应用方案。
但如果你是 Go 开发者，正在寻找一种更轻、更贴近 Go 技术栈的桌面开发方式，Wails 真的值得试一试。
它不是 Electron 的终结者。
它更像是 Go 开发者进入桌面应用开发的一张新船票。
