因为没人做。

不是不适合做，更不是做不出来。

根本原因是工作量太大，参考：

看看 C++ 写个跨不了平台的小 GUI 库得有多少工作量。


Go 的 GUI 有两类。

一类是对其他 GUI 库的 binding，没什么好说。

另类是原生实现。


Go 有 IMGUI 的原生实现，但 IMGUI 的缺点是业务和 GUI 代码耦合太高。

而降低耦合度又能提供足够灵活强大的 GUI 组件，就得实现类似 CSS 的布局机制，引入能操控布局和控制动画的脚本语言。最好的实现实际就是重造一套类似浏览器那套，组件标签化，CSS管布局，然后脚本操纵也就是弄个vm，在这之前还得自己实现 Skia 那样的反锯齿绘图库，这些工作量和难度比写个 web 框架或网络中间件大多了。

这还没到 Graphic API/input 这层，你还得考虑你的 draw API 和 Input 回调是基于 SDL2 /GLFW 这类跨平台封装库还是直接就穿到各 OS 上，自己做跨平台封装，问题是现在 Graphic API 都还在大换血。


另外这和 Go 调度模型没任何关系。

所有需要 context 绑 main thread 的都有自己的 mq，其他线程搞定业务处理和更新组件树，产生 graphic cmds，然后各批次 graphic cmds 往这个 mq 抛，绑在 main thread 上的 handler 最后才会真正发起对 graphic API 的调用。

所有 IMGUI 都有自己独立的 cmd queue， C/C++ 写的也是这么搞。

Go 的变参闭包鸭子chan搞这套反而超级简单。


真正的困难是，Go 写后端，缺啥轮子几千行就能造一个，其他语言能抄的实现也有一大把。

而做 GUI，缺轮子你写个麻雀也得大几万行，资料少不说，要抄的还都是百万行的项目。与其愚公移山，不如用其他语言的成熟框架搞个前端，然后 go rpc 更简单。