2026 年 10 月 26 日，Wails 项目正式发布了 v3.0.0。距 2023 年 1 月第一个 alpha 版本发布，这个"下一代版本"打磨了近四年，如今终于摘掉了 alpha/beta 的帽子，进入正式可用状态。
对不熟悉 Wails 的读者简单介绍一下：Wails 是一个用 Go 构建桌面应用的框架，前端写 HTML/CSS/JS，后端写 Go，两者通过自动生成的绑定互相调用。它不打包浏览器，而是直接使用操作系统自带的 WebView（Windows 上是 WebView2，macOS 上是 WKWebView，Linux 上是 WebKitGTK）。这个思路和 Tauri 一致，也是它与 Electron 最本质的区别。
一、和 Electron 比：更小、更省、更快
Electron 把整个 Chromium 和 Node.js 打进每个应用，换来的是行为完全一致的运行环境，代价是：
-
体积：一个 hello world 应用动辄 80~150MB 的安装包；
-
内存：每个应用都带着一份完整的浏览器，多开几个应用内存立刻爆炸；
-
后端语言：Node.js 在系统调用、并发、单文件分发上不如 Go 顺手。
Wails 的做法是复用系统自带的 WebView，Go 负责后端：
-
安装包只有几 MB 量级，体积比同功能 Electron 应用小一个数量级；
-
内存占用显著更低，因为不加载捆绑的 Chromium；
-
后端是纯 Go，编译成单文件二进制，跨平台交叉编译一行命令搞定，类型安全、并发模型和标准库都是加分项；
-
Go 的 GC 和 Node 的 V8 在桌面场景下都能满足需求，但 Go 做网络服务、系统交互（SSH、文件传输、协议处理）这类工作明显更自然。
当然要公平地说：Electron 的优势在于"每个应用自带的浏览器版本完全可控"，不用操心系统 WebView 的版本差异。早些年 WebView2 在 Windows 上尚未普及、不同机器版本参差不齐，这确实会带来一些诡异问题；如今 WebView2 已随系统自动更新，这一点顾虑基本消除。
二、和 Tauri 比：同一个方向，不同的后端哲学
Tauri 是这个赛道上最直接的"同路人"：同样使用系统 WebView，同样主打小体积。两者的核心差异在后端语言：
-
Tauri 用 Rust：性能与安全性天花板更高，生态插件更丰富，Tauri 2 已经稳定支持移动端；
-
Wails 用 Go：上手门槛低得多。Go 语法简单、编译快、goroutine 处理并发毫不费力，绝大多数业务开发者从 Node、Python 甚至其他语言转过来，一两周就能产出可用的后端，而 Rust 的所有权、生命周期和异步生态的学习曲线是实打实的存在。
选型建议很简单：团队已有 Rust 能力、追求极致性能和插件生态，选 Tauri；团队主力是 Go、或者想快速把现有 Go 代码包成桌面应用，选 Wails。Wails v3 同样支持 iOS 和 Android，一套 main.go 和前端代码可以直接跑在移动端，移动端不再是桌面框架的短板。
对 Go 团队而言，Wails 有一个 Tauri 无法替代的价值：你的后端就是一个普通的 Go 程序。已有的 Go 库、内部服务、业务逻辑可以直接复用，框架只负责把它"绑"到窗口上。
三、v3 相比 v2：不是升级，是重写
Wails v3 是一次推倒重来的重构，官方也明确说明从 v2 迁移是一次真正的移植而非版本号变更。核心变化：
1. 显式的应用模型。 v2 中应用、窗口、事件都藏在隐式的生命周期和 context 里；v3 把 Application、Window、Service、Event 都变成显式对象。多窗口、系统托盘、后台服务从"社区 hack"变成框架一等公民——对托盘常驻、多窗口这类需求，用过 v2 的开发者都懂有多痛。
2. 服务化的绑定。 后端注册 Service，导出方法自动暴露给前端；wails3 generate bindings 基于静态分析生成 TypeScript，连文档注释和真实参数名都会带过去，Go 结构体映射为 TS 类、Go 枚举映射为 TS 枚举。还支持流式数据和自定义传输。
3. 原生 UI 能力大幅补齐。 系统托盘（含明暗图标、窗口附着）、应用菜单与上下文菜单、原生对话框、系统通知、全局快捷键、文件拖放、开机自启、macOS 的刘海窗口和 macOS 26 的 Liquid Glass 毛玻璃效果——这些在 v2 里要么没有、要么要靠第三方库。
其中文件拖放值得一提：v2 里原生的拖拽支持还是实验性质、可用性有限，实际开发基本只能走 WebView 的网页上传模式；v3 提供了原生文件拖放，拖入的文件以真实路径交给后端 Go 处理，对大文件传输、批量导入这类场景尤其友好（原有的 HTML 拖放也继续保留）。
4. 内置应用更新器。 可插拔更新源（含 GitHub Releases）、加密签名校验、原子替换与回滚，还带一套可换肤的默认 UI。这在 v2 里是完全空白、只能自己造轮子的领域。
5. 可读的构建系统。 v2 的 wails build 是一个黑盒；v3 改用 Taskfile，构建流程全部可见、可改、可调试，代码签名、NSIS/MSIX、DMG、AppImage、deb/rpm 打包都有官方支持。交叉编译同样是一等公民。
6. 移动端支持。 同一套 main.go 和前端代码可以直接构建 iOS 和 Android 应用，桌面与移动共享一份业务逻辑，Go 后端的能力原封不动地带到手机上。另外还有 Server 构建模式（同一套应用直接以 HTTP 服务运行）、可让 AI 工具驱动运行中应用的 MCP 服务等新玩法。
需要提醒的是：v3 要求 Go 1.26 及以上；Linux 端默认切到了 GTK4 + WebKitGTK 6.0。
四、真实项目验证：uniTerm 已在 beta 上跑了一个完整周期
这不是一篇纸面评测。我们的开源项目 uniTerm（一个基于 Go + xterm.js 的 SSH/SFTP/RDP 多协议终端客户端，涉及高频终端数据流、大量系统级交互）早在两个月前（2026 年 8 月底）就已全面切换到 Wails v3（当时是 v3.0.0-beta.12），并跟随 beta 版本迭代至今。
一个终端客户端对框架的考验相当苛刻：成千上万行/秒的终端输出要经 Go 后端实时推送到前端渲染，多窗口、系统托盘、全局快捷键、文件传输、协议处理样样都是重交互。在近两个月的 beta 版本使用中，框架层面的稳定性表现超出我们的预期：高频的终端数据流、多窗口、系统托盘这些重交互场景，都没有出现需要绕开框架去打补丁的情况。
当时选择在 beta 阶段就切换，看中的正是 v3 的架构：显式的窗口/服务模型让我们能干净地实现多会话窗口和托盘常驻，基于静态分析的绑定让前后端协作几乎零摩擦。更让我们惊喜的是移动端——在几乎没有代码变更的情况下，同一套代码直接在 iOS 和 Android 上跑通了。如今 v3.0.0 正式发布，意味着这个曾经需要一点冒险精神的决定，变成了可以放心推荐给所有人的选择——现在入坑 Wails v3，没有"等正式版"的顾虑了。
uniTerm 完全开源（Apache 2.0）：github.com/ys-ll/uniterm。如果你也在做 Wails 应用，可以直接参考它在终端、远程桌面、数据库与 K8S 管理方面的实践——高频数据流的前后端推送、原生能力的封装都是现成的例子。
五、上手
# 安装 CLI（要求 Go 1.26+）
go install github.com/wailsapp/wails/v3/cmd/wails3@v3.0.0
# 引导式环境检查与依赖安装
wails3 setup
# 创建新项目（vanilla/React/Vue/Svelte × JS/TS 模板任选）
wails3 init
# 开发模式：前端热重载 + Go 自动重建
wails3 dev
已有 v2 项目的用户，官方提供了迁移指南（wails.io 的 Migration 章节）。坦率地说迁移有一定工作量——应用生命周期、绑定方式、runtime 调用都有变化——uniTerm 虽然借助 AI 进行了大量重复性的代码调整，但也花了近一周的时间来进行测试调优。不过，wails v3 带来的能力提升，完全值得这次重构花费的时间。
结语
桌面跨平台开发长期以来只有两条路：要么接受 Electron 的体积与内存，要么征服 Rust。Wails v3 的正式发布，让"Go 语言 + 系统原生 WebView"这条中间路线第一次具备了生产级的完整度：多窗口、托盘、更新器、打包签名、移动端实验支持一应俱全。
如果你的团队熟悉 Go，或者手里有一堆 Go 代码想做成桌面应用，现在是认真评估 Wails 的最好时机。想看看社区里用 Wails 做出了哪些应用，可以逛逛官方维护的 awesome-wails 列表：github.com/wailsapp/awesome-wails，从工具、面板到游戏客户端都有，uniTerm 也在其中。