我在搞Go桌面GUI这方面，简单解释下，Go搞桌面跨平台软件有几个问题：
一、跨平台GUI本身就不好做，
目前成熟可用的系统级跨平台GUI框架其实并不多，Native与系统原生组件关联的的其实只有Qt、Gtk、wxWidgets，其他要么是SDL、GLW之类的绘图引擎、要么是Electron这类基于浏览器的，要么是JavaFX、SWT、AWT、Swing这类基于Java的，当前其他还有很多零零碎碎的跨平台GUI框架，有些在某些方面还挺好用的，但基本都不全面。
比如我需要做一个全屏和窗口截屏软件，上述很多框架都做不了，更别说一些小框架了，那些只能靠你自己去桥接自己基于系统API写的各个平台的截屏组件了，别提多蛋疼了。
另起炉灶重新做一个完美可用的系统级GUI其实是非常困难的，做一个能用在某些领域的很简单，我一个月就能撸一个，但这并不是一个真正可用的GUI。目前Go这边真正在尝试这么干的其实只有类似fyne这样的框架，但fyne是基于OpenGL和GLFW实现的，先天受到OpenGL的一些限制，无法像基于系统GUI的一些框架那样完美兼容系统，比如上面的截屏就做不了，另外，MacOS最新的版本已经废弃OpenGL了，接下去会改用Metal，这个项目有得好蛋疼了，我不看好。
二、CGO和GO的差异
无论你怎么弄，跨平台GUI都必须要与操作系统交互，与系统API交互就意味着得引入CGO，而用了CGO就会一定程度上丧失跨平台性和安全性，甚至某种程度上你都不能再认为这是一个Go的GUI框架，而只是一个Go语言能用的C框架。
三、Go没有动态库
没错，我知道Go可以调C的动态库，但Go没有自己的动态库，这看似是一个和GUI不想关的问题，但其实很重要。因为目前可用的很多免费的跨平台GUI库都是LGPL的，没有动态库，就没有绕过LGPL的途径，绕不过LGPL搞屁搞，本来我还想用therecpt的Qt绑定库做应用的，结果发现根本没法商用，除非把GUI和业务写成两个可执行，或者把我的代码打成C库，搞毛啊。
四、跨平台GUI库真的很难写
一个文本排版和渲染就能写死你信不信，我第一次写的时候整整折腾了半年。
最后，那Go就不能做GUI了吗？可以，我觉得，如果要用Go来实现跨平台GUI，可以先实现一个类似浏览器的核心程序，基于OpenGL、DirectX、Metal做，我们可以认为他是个GUI Runtime，就像MacOS上的Xorg一样，是一个系统GUI接口和Go之间的桥接程序，然后Go语言编写的三方应用再以某种方式与改程序进行桥接。
但这样的缺点就是需要用户先额外安装这个工具了，感觉变麻烦了呢。
