我把自己的 Agent 从 Wails 迁到了 MyGo 原生 GUI，全程踩坑和实践分享
最近把自己写的工作 agent Ally agent 的界面重写了一遍，起因是无意中看到有人推荐 MyGo ，加上我对内存和性能一直有点追求，多年来一直在用 wails ，想换个试试，就想拿自己的项目试点，没想到结果意外的不错。 旧版本的技术栈是典型的 Go + Wails + Vue （ wails 我用了很多年 最近终于 V3 发正式版了 等了四年，可惜我也老了 ），界面用 Naive UI ，样式美观，效果也相当不错。但做久了有几个地方比较麻烦（ tarui 应该也是一样）： 跨平台界面的细节不一致，构建链比较长，还有前端内存出了问题以后，我这个写后端的人不太容易排查。 折腾了一段时间，现在主要页面已经迁到 MyGo 了，记录一下过程中比较有感触的地方。 先说一下技术路线：Wails 的界面通过系统 WebView 展示网页； MyGo 既支持这种方式，也支持用 Go 写 Native UI ，由框架自己绘制。WebView 也有自己的优势，MyGo 两种都支持，相当于有个兜底，下面会说。 Ally 现在的聊天、设置等常用页面用 Native UI ，插件页面和部分预览仍然按需使用 WebView 。 一、UI 跨平台一致性 这是我这次迁移最重视的一点。 之前用 Wails 做界面，Windows 上调好的页面，到了 macOS 上经常还要再看一遍。字体、行高、滚动条、输入框这些地方，偶尔就会有一点不一样。 比如我画的表格，不知道为啥线条在 macOS 上看着发虚，Windows 上就正常。单看问题都不大，但调整完一个平台还得顾着另一个平台，挺烦的。 Wails 使用系统 WebView ，Windows 和 macOS 背后的浏览器引擎不一样，前端样式最终要经过各自的渲染实现。 MyGo 的 Native UI 由框架自己负责布局和绘制。迁移后，我在 Windows 上调好的主体界面，拿到 macOS 上看到的效果接近得多，需要针对平台单独修的地方也少了。 当然，自绘也不等于所有像素都完全一致。MyGo 的文字排版仍然使用 各平台的文字系统 ：Windows 是 DirectWrite ，macOS 是 Core Text ，Linux 是 Pango 。字体回退、DPI 、输入法这些还是要分别检查。但至少不用再同时处理两套 WebView 引擎带来的样式差异了。 以前总觉得 Electron 重，碰到这些问题后倒是能理解为什么有些项目愿意用它：自带 Chromium ，渲染环境相对好统一。OpenCode 桌面端后来也 从 Tauri 换到了 Electron ，不过人家具体为什么换，我就不瞎猜了。 二、内存问题现在能用熟悉的 Go 工具查 以前 Wails 版本的 Go 后端一样可以用 pprof ，但界面在 WebView 里，Go 堆、JavaScript 堆、DOM 、浏览器渲染进程是几块不同的东西。 前端也有 DevTools ，可以拍 JS heap snapshot 、查 DOM 引用。但我平时主要写 Go ，遇到界面内存持续上涨，分析起来没有 Go 那么顺手。 现在主要界面和业务都在 Go 进程里，我给 Ally 加了一个按需导出诊断的入口：在设置里点“导出内存诊断”，会导出 heap.pprof 、 allocs.pprof 、 goroutine.pprof 等文件。 比如在空闲时导出一次，复现内存增长后再导出一次，就可以对比： go tool pprof -http=127.0.0.1:0 \ -base=before/heap.pprof after/heap.pprof heap 主要看还活着的对象， allocs 主要看累计分配。分配量大不一定是泄漏，也可能是某段代码反复创建临时对象，GC 能回收，但会持续消耗 CPU 。 当然，pprof 主要看到的是 Go 堆。系统和 GPU 资源，以及 WebView 子进程的内存，还是得用其他工具看。 三、帧处理的坑 MyGo 的界面更新会重新构建控件树，写 UI 时要特别留意渲染函数里做了什么。 我的 Agent 有命令执行卡片，命令输出可能很长。之前即使卡片折叠着、界面上只展示最后几行，代码仍然会先把整段输出拆分、去空行，再取出末尾几行。 看起来只是一个字符串处理函数，但界面更新时会反复执行。 后来改了两处： 只需要末尾几行时，从字符串尾部向前扫描，不再先拆分整个输出。 需要重复使用的派生结果按原始内容缓存；内容没变就复用。折叠时不构造展开用的行数据，并释放对应缓存。 一次本地测试里，用两万行命令输出测试折叠卡片的相关处理， 单次分配从约 1.9 MB 降到 1.9 KB ，耗时从约 0.72 ms 降到 0.02 ms 。 这是这段处理在该样本下的局部结果，不是整个应用的性能对比。 对应修改在这里 。 类似的问题还有工具参数 JSON：同一条消息的卡片头、卡片体都可能读取参数，如果每次渲染都 Unmarshal 一遍，长对话里分配会越来越明显。现在把解析结果挂在控件局部状态上，原始参数变化时才重新解析。 我的感受是，性能问题要先分清楚是“ 每次请求执行一次 ”，还是“ 界面更新时每帧执行一次 ”。后者哪怕单次看着不重，乘上帧数和控件数量也很拖累性能。 四、构建链变短 旧项目的构建大致要经过前端依赖、绑定生成、Vite 构建，再编译 Go 。MyGo Native UI 的主要页面直接用 Go 写，主界面去掉了前端打包这一步，我自己的项目构建起来明显快了不少。 MyGo 不依赖 CGO ，交叉编译也省事。目前 Ally 的构建脚本可以在 macOS 上处理 Windows 、macOS 、Linux 的 x64 和 ARM64 六个目标，另外生成 macOS Universal 包。 例如编译一个 Windows x64 二进制，核心就是： CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o Ally.exe . 实际发布还要处理资源、压缩包、签名等事情；能交叉编译出来，也不代表已经在目标系统完成运行验证。Linux 的图形环境和使用 WebView 时需要的系统库，也仍然要考虑。 这里补充一下：我刚看了 Wails 3.1 的发布说明 ，它也加入了无 CGO 构建能力。目前 macOS 和 Linux 的 purego 后端还是实验性质，CGO 仍是默认选项。 所以“无 CGO”以后不一定是两者之间的主要区别。对我这个项目来说，更明显的差别是主界面不用再经过 Vue 那套构建流程了。 五、MyGo 组件够用，但 Web 生态还是强很多 迁移前我担心原生 GUI 要从头写一堆控件，实际比想象中好一些。 MyGo 已经有常见的表单、列表、树、弹窗，也有代码编辑器、Diff 、Markdown 等组件。Ally 的文件浏览和代码编辑用到了它的编辑器，聊天内容也用到了 Markdown 相关能力。 但如果和成熟的 Web 组件库比，差距还是很明显。Naive UI 这类库积累了很长时间，一个表单、选择器或者弹窗拿来就能用，样式、焦点、键盘操作、动画都比较完整。 好在 MyGo 的定制能力不错，但要做出自己满意的效果，颜色、间距、状态和交互细节还是得花时间。我之前不太想碰这类原生 UI ，一个原因就是觉得