Wails 3 发布了，能追上 Tauri 吗？

一、四年磨一剑：Wails v3 终于来了

2026 年 10 月 26 日，Wails 正式发布 v3.0.0。从 2023 年 1 月第一个 v3 alpha 标签算起，到今天稳定版落地，整整走了将近 四年。这中间有无数个测试版、崩溃报告、翻译贡献和架构推倒重来。作者在发布公告里毫不掩饰地说："It has been a long road."（这是一条漫长的路。）

对 Go 开发者来说，Wails 的意义一直很清晰：用你已经熟悉的前端技术（HTML/CSS/JS，或 React、Vue、Svelte）做界面，用 Go 写后端逻辑，再用各平台原生的 WebView 把它包成一个真正的原生桌面应用——而不是塞一个 Chromium 进去。v3 不是一次小升级，而是一次从地基开始的彻底重写。它今天能追上老对手 Tauri 了吗？我们需要先把"它到底改了什么"讲清楚。

二、为什么要从零重写：v2 的"单窗口天花板"

Wails v2 把"用 Go 写后端、用网页做界面"这件事变得很顺手，它服务了大量应用。但它有一个结构性的天花板：单一窗口、以 context 驱动的运行时。你想做多窗口？想挂一个系统托盘？想跑一个常驻后台服务？在 v2 里这些都不是一等公民，而是一堆"变通方案"（workaround）。

v3 的起点完全不同：应用（Application）、窗口（Window）、服务（Service）、事件（Event）和平台能力，全部变成你可以直接创建、直接对话的显式对象。应用长大了，结构依然清晰；多窗口从" hack"变成了"模型的一部分"。

三、重构核心：一切皆对象

这是 v3 最有价值的变化，也是迁移成本的主要来源：

• Application 对象：你显式地创建一个应用，向它注册服务、创建窗口，再跟"拥有你需要行为的那个对象"对话。
• Window 对象：运行时可以创建、显示、隐藏、关闭任意数量的窗口，每个窗口有自己的配置、事件和生命周期。
• Service 对象：你的后端就是普通的 Go 代码。把 service 注册到应用上，它导出的方法就能被前端调用；service 还能带启动/关闭钩子，甚至直接对外暴露 HTTP 路由。
• Manager API：窗口、菜单、对话框、事件、屏幕、剪贴板等，都通过应用上的"管理器对象"来访问，而不是一个被 context 绑死的 runtime 包。
• Typed Events：应用级、窗口级、自定义事件，都带类型化负载，Go 和 JS 两端都能用，还支持平台系统事件。

四、桌面能力全景：多窗口、托盘、菜单、Liquid Glass

v3 把桌面集成的"零件库"补齐了，而且是原生实现：

• 系统托盘：带菜单，支持亮/暗图标、macOS 模板图标，还能把窗口挂到托盘图标上。
• 菜单：应用菜单、右键上下文菜单（甚至可以用 WML 属性从 HTML 里定义）、托盘菜单，都支持运行时更新。
• 对话框：原生消息框、提问框、文件选择/保存框，外加自定义对话框。
• 无边框与自定义窗口：原生圆角与阴影、自定义标题栏、拖拽区域、半透明，甚至 macOS 26 上的原生 Liquid Glass（旧版本有降级方案）。
• 通知、全局快捷键（macOS 上字母快捷键会跟随 AZERTY/QWERTZ/Dvorak 等键盘布局的实际按键）、Dock 角标、开机自启、打开 URL/文件、macOS notch 窗口、按窗口维度的摄像头/麦克风/定位权限地图。

五、绑定生成：静态分析取代运行时反射

v2 的绑定靠运行时反射，方法名和注释在前端经常"失真"。v3 改成 wails3 generate bindings——它通过静态源码分析读取你的 Go 源码，于是文档注释、真实参数名都能原样带到生成的 TypeScript / JavaScript 里。Go 的结构体变成 TS 的 class 或 interface，Go 的枚举变成 TS 的 enum。还能在 Go 与前端之间流式传输数据，或在需要完全掌控时用裸消息和自定义传输。

六、构建与分发：看得见的 Taskfile、升级器、签名安装包

v3 的构建系统是一个显著的人体工学改进：

• 看得见的构建：项目改用基于 Taskfile 的构建流程，你可以读、可以扩展、可以调试，而不是一条不透明的命令。
• 跨平台编译：官方给了在每个桌面目标上"为它编译"的指南。
• 代码签名与安装包：每个平台都能签名；Windows 有 NSIS 和 MSIX，macOS 有 DMG 和 app bundle，Linux 有 AppImage、deb、rpm 和 Arch 包。
• 应用内升级器：可插拔的 provider（含 GitHub Releases）、加密校验、原子替换加回滚、还有一套可换肤或替换的默认 UI。
• 单实例、文件关联、自定义 URL 协议；外加混淆构建和访问私有 macOS API 的能力。
• Server 构建：同一套应用和 service 可以当成没有原生窗口的 HTTP 服务跑。

七、平台与移动端：Linux 默认 GTK4，iOS/Android 仍"实验"

v3 覆盖了 Windows（amd64 / arm64）、macOS（Intel / Apple Silicon）和 Linux（amd64 / arm64）。一个值得注意的变化：Linux 默认改用 GTK4 加 WebKitGTK 6.0，旧的 GTK3 栈还能用 -tags gtk3 撑到 v3.1。

移动端方面，iOS 和 Android 是实验性的：同一份 main.go 和前端理论上能跑在手机上，但文档明确说它不在"稳定桌面兼容性承诺"之内，建议当探索性能力来用、出了问题去反馈。对比一下就能看出差距——这正是下面要和 Tauri 掰手腕的地方。

八、性能对比：Wails 3 vs Tauri 2

先把两家的"官方口径 + 社区实测"摆在一起。注意 Wails 官方对标的是 Electron，而 Tauri 是它真正的同赛道对手。

几个关键读数：

• 启动：Wails 是单进程模型，省掉了进程间通信的初始化步骤，冷启动通常比 Tauri 快 100–300ms；但 Tauri 的多进程架构在热启动时差距会明显缩小。
• 内存：两家都很轻，单窗口常驻都在几十到一百多 MB 的区间，远小于 Electron 的 200MB+。
• CPU / 延迟稳定性：Go 的 GC 在持续高负载下可能引入毫秒级的短暂延迟尖峰；Rust 没有 GC、靠所有权实现零成本抽象，在实时性要求极高的场景（音频处理、高频数据采集）表现更稳。日常 CRUD 场景下，这个差距工程上基本感知不到。

九、安全模型：内存桥接 vs 能力白名单

这是最容易在"体积对比"里被忽略、但在生产环境最关键的维度。

• Tauri 2：默认安全-by-config。WebView 默认零系统访问，前后端通信走基于事件的 IPC，受"能力（Capabilities）"白名单管控，默认拒绝一切（deny-by-default），并且经过独立安全审计。
• Wails 3：用 OS WebView，原生访问权限握在 Go 后端手里，前后端是内存桥接（In-memory bridge），不监听网络端口。v3.0.0 修掉了几乎所有已公开的安全公告，但仍有两个"已知限制"值得警惕：Linux 下同源子帧（如 about:blank iframe）仍能触达原生消息处理器；Android 实验版把 window.wails 桥接暴露给了 WebView 里的每个 frame。官方建议：不要在前端里嵌入不受信任的第三方内容。

十、生态与操作变化：Go 的 DX 优势 vs Rust 的成熟生态

这一节直接回答"操作上的变化"：

• 包管理与依赖：Go 的模块系统成熟简洁，go.mod 对新手友好，标准库质量高（网络、加密、JSON 几乎不用额外依赖）。Rust 的 Cargo 生态极其丰富，crates.io 的包数量远超 Go，但编译时间明显更长，首次或依赖多时可能要等几分钟。
• 社区与资源：Tauri 的 GitHub Star 数和社区规模明显大于 Wails，第三方教程、插件、模板更丰富；Tauri 还有官方维护的插件体系（tauri-plugin-*），覆盖文件系统、通知、系统托盘等。Wails 社区虽小，但核心开发者活跃，Issue 响应通常在数小时到一天内。
• 原生 OS 绑定：涉及系统原生框架（如 macOS 的 ScreenCaptureKit）时，Rust 有成熟封装 crate，全程写 Rust 即可；Go 生态里这类封装较少，但 Go 内置 CGO，可以直接写 Objective-C 对接 Apple 框架——能力等价，只是更"底层"一点。
• 移动端：这是目前最硬的差距。Tauri 2.0 的移动端（iOS / Android）已经正式 GA，是"桌面 + 以后可能上移动"场景的唯一现成选项；Wails 的移动端还停在实验阶段。

十一、从 v2 迁移：这是一次真正的"移植"

v3 是新的大版本，迁移是一次真正的 port，而不是改个版本号。主要变化集中在四处：应用和窗口的生命周期、用 service 取代 context 绑定的绑定、用直接的应用/窗口 API 取代 v2 的 runtime 包、以及重新生成前端绑定。官方提供了 v2-to-v3 迁移指南，带前后对比示例。

好消息是：v2 不会消失，仍会收到关键更新；两个 CLI（wails 与 wails3）是不同的二进制、不同的模块路径，可以共存。新项目直接用 v3.0.0。

发布节奏上，v3 之后改为每周一次小版本（v3.1.0、v3.2.0…）、每日 nightly 预发布预览下一版，以及按需的 patch 热修。Go 的 @latest 永远指向最新的周版或热修，绝不会指向 nightly。

十二、结论：Wails 3 追上 Tauri 了吗？

直接给判断：

在纯桌面（Windows / macOS / Linux）这条赛道上，Wails 3 确实追上了，而且是一次体面的反超。它补齐了多窗口、托盘、菜单、对话框、升级器、签名安装包这些 v2 时期的短板；静态分析生成的类型化绑定让 Go 与前端协作的体验丝滑；单进程模型在启动速度和开发调试体感上甚至略胜 Tauri；而 Go 的编译速度和上手曲线，对 Go 团队来说是实打实的效率优势。

但在三个维度上，Tauri 仍然领先，Wails 3 还没追平：

• ① 移动端：Tauri 2.0 的 iOS/Android 已 GA，Wails 还只是实验性；
• ② 安全成熟度：Tauri 的能力白名单 + 独立安全审计，比 Wails 的内存桥接 + 已知限制更让人放心；
• ③ 生态规模：Star 数、插件体系、第三方模板与教程，Tauri 的体量目前仍明显更大。

所以一句话总结：如果你是 Go 团队、只做桌面、看重开发效率和启动体感，Wails 3 现在就是比 Tauri 更省心的选择；如果你要移动端、要极致的权限安全模型、或本来就是 Rust 栈，Tauri 依然是该领域的标杆。"追上"在桌面上已经成立，在生态与移动端，故事才刚刚开始。

参考：Wails v3.0.0 Release Notes、Wails 官方博客与文档、Tauri 2 官方文档，以及 2026 年多篇社区横向评测。