Wails作为一个使用Golang开发跨平台桌面端的框架，几乎是目前Gopher唯一的选择，当然也有其他框架可选，但是个人感觉都不太成熟。本人使用Wails开发Tiny RDM不知不觉已有半年，现就这段接触使用时间来做个大概总结分享。

优点

1. 打包包体极小

由于并不包含浏览器运行时，所以包体随便能到10M以下。但并不意味着内存占用小，和附带浏览器的electron类应用相比，实际运行起来内存占用半斤八两，毕竟本质都是web应用套壳。

2. 开发体验接近Web全栈开发

如果你是个gopher，又刚好会写点前端网页，那wails会是你很好的选择，开发时也能直接浏览器运行，即改即刷新，开发些小工具速度一流。

3. 前后端自动绑定

只要Go中声明要导出的结构体实例，写好接口方法，就能自动生成JavaScript方法声明，直接调用即可，无论是Go端的结构体，还是JavaScript端的数组/对象，都能比较友好地进行转换。而且还有基于通知的双端通讯实现，方便进行频繁的数据传输。

4. 可自定义资源服务

这也是基于Web的App一个好处，通过自定义资源路径来决定本地资源读取路径，甚至是读取远程资源文件，可以以此为基础实现资源热更新。

缺点

1. 兼容性一般

这个electron类应用的优势就体现出来了，毕竟不同平台上的浏览器内核或多或少都会有差异。有时会遇到一个正常的写法在Windows和macOS上运行得好好的，在Linux上就错位了，这让我想起了IE6/7/8/9时代的噩梦。比如在一些旧版本的系统上(有用户反馈win10也会)，甚至会出现整个页面都是白屏或者不显示，这相关的几个issue目前还躺在那等着大牛来处理~相信随着时间的推移，和新老版本操作系统的更替，这些不兼容性的问题会逐渐消失，基于Webview开发的应用也会越来越多。

2. 运行效率一般

由于前后端语言不一致，一些复杂的逻辑和数据操作也通常会使用Go来处理，处理完成后需要发送给前端进行展示，中间涉及到前后端通讯就会有所消耗。而且Web前端处理能力上限不高，所以瓶颈往往也在这。在一些比较复杂的界面，比如树形列表，进行一次大量的增删操作，往往需要拆分多次来处理，拆分后每次处理的量实际也不好把控，数量多了容易导应用假死，数量少了一个完整的操作就需要耗费更多等待时间。

3. 系统级的接口不够

同为基于Webview的Tauri相对会好一些，但这个还是比electron差太多了。比如我想监听主窗口的尺寸和位置变化，并实时保存变化后的值方便下次启动应用时恢复，也只能依靠些奇技淫巧来解决（新开个goroutinue来定时获取和判断窗口是否有变化）。像比较常用的多窗口支持和系统上下文菜单等等，wails目前也是缺失的。

4. 打包工具不完善

虽然通过wails cli就能打包，但是整体体验还是差强人意，Windows和macOS上还算够用，但Linux上就不太舒服了。目前Tiny RDM打包使用的是Github Action，配置文件部分参考了另一个使用wails的开源项目october并做了自定义修改。目前Tiny RDM仅支持deb安装包，但是Linux版本众多，依赖的Webview也各不相同，所以deb有时都不能做到即装即用，还要安装Webview运行时等等（这个问题在旧版的Windows上也有）。其中呼声最高的appimage格式，目前我也暂时无能为力。

5. 不支持导出Web端

这个和上一点说的有些重复，单独作为一点是因为它本身就是基于Web开发的应用，大部分人应该都默认它原生支持Web模式了，但实际上却不支持导出Web版本，这多少还是有点说不过去。目前开发模式下可以直接通过浏览器运行和调试前端，但也仅限于开发模式下了。并且包括一些系统接口也不支持Web端的，如打开对话框选择文件，Web模式下打开的却是在App端的系统文件选择对话框。不过真正麻烦的应该是Go后端逻辑没法在浏览器运行，相信随着Golang的Webassembly逐步成熟，后续官方会支持起来的。

6. 没有原生自更新

上面优点中提到了它的资源管理器可以方便热更新，但是仅限于前端页面，涉及到Go编写更改的部分，仍然是需要重新安装的。在快速版本迭代的现今，自更新可以减少用户使用新版本的障碍，目前自更新wails官方也加入到了roadmap中#1178，相信不久将来这个反而变成它的优点了。

7. 插件市场不丰富

wails目前没有官方的插件市场，也就只能依靠丰富的Web插件和不太丰富的Golang第三方依赖了。但比较尴尬的是，NPM上也只能使用纯前端插件，而Go的依赖大多数是为了服务后端的，服务于操作系统的不多，比如Tiny RDM中用到的第三方依赖userdir，用于获取本机中用户数据目录的，最后一次更新是9年前了；再比如其中用到的获取系统字体的第三方依赖sysfont也无法完整拿到系统内建字体列表。所以即使前后端语言都有生态市场，但都挺难用于wails上。

8.没有调用系统接口的能力
无法在Go中调用其他语言的系统接口，导致缺少很多灵活性，或者说是个限制。举个例子，我想上App Store，但是我无法接入内购，只能作为付费下载来使用了。

以上仅仅是个人的观点和使用感受，不代表一个框架一定得有个高低优劣之分。我个人最终的结论是：基于Webview的应用目前还是不太适合用来开发商业应用，但是很适合想快速做一些小工具的。当然它随着开发者使用者增加，也日趋完善，还有roadmap中计划支持Android和iOS都是比较令人期待的。

使用Wails的正经开源项目不多，最后附上本人开源项目Tiny RDM，这是一个跨平台的Redis桌面客户端，轻量美观易用，功能齐备（基本和市面上的客户端齐平），既有颜又能打。也可为打算使用Wails开发的小伙伴用作参考，代码工整，也有必要注释（都是英文注释，因为后续打算让老外也用上国人开发的软件，我们也能做出优秀的作品）。如果这个项目对你所有帮助，给我点个star就是对我最大的支持了~

官网地址：https://redis.tinycraft.cc
源码地址：https://github.com/tiny-craft/tiny-rdm