Wails v2 实战：用 Go + Vue3 做一个真正能用的 AI 桌面应用

事件核心：发生了什么

这是「AI 详情页生成工具」系列的第 2 篇，偏向实战教程。项目技术栈为 Go 1.26、Wails v2.15、Vue 3.5 与 TypeScript，采用 Vite 7 手工搭建前端骨架，数据库用 gorm + SQLite（纯 Go 驱动 glebarez）。作者给出的选型理由有三点：商品图属于卖家核心资产，主打“图片只走用户自己的模型账号、排版合成在本机完成、服务方不经手不存储”；750px 长图合成与系统 CJK 字体渲染直接由 Go 完成，不走网络；用户 API 密钥通过 AES-GCM 加密后只存本机用户目录。

文章还公开了目录结构与组合根写法：main.go 按“数据库 → 配置 → 密钥库 → 服务 → App”装配，前端构建产物通过 //go:embed 嵌入二进制，发布只有一个文件；数据目录统一走 os.UserConfigDir()，跨 Windows、macOS、Linux。原文提到 Wails 产物约 20MB 级别，对比 Electron 动辄 200MB+ 的打包体积和更高的常驻内存。

为什么重要

对 AI 应用开发者来说，这篇文章的价值不在“又一个桌面壳”，而在于它把 BYOK（自带密钥）和本地推理之外的“本地业务处理”路线讲清楚了。大模型调用仍走 OpenAI 兼容网关，但流水线调度、位图排版、密钥加密全部留在 Go 侧，前端只做展示层，这为隐私敏感型 AI 工具提供了一种可复用的架构模板。同时，app.go 只做参数校验与转发，并用 AST 写架构护栏测试，禁止其 import gorm/database——桌面应用容易写成“一锅炖”，这种靠机器守分层纪律的做法值得借鉴。

对用户/开发者/创作者的影响

开发者可以据此评估 Wails 与 Electron 的取舍：若重活集中在 Go，Wails 能省掉 Node 主进程那一套，但代价是 WebView 碎片化——Windows 依赖 WebView2，Linux 需 libgtk-3-dev 与 libwebkit2gtk-4.1-dev，不同内核偶有 CSS 差异。文中也给出几个易踩的坑：BackgroundColour 要与前端主题底色一致以防启动白闪；macOS 上 Frameless: true 会让红黄绿交通灯消失，应改用 mac.TitleBarHiddenInset()；生成的本地长图需通过 AssetServer 挂载的 http.Handler 以 /local/ 前缀暴露，因为 img 标签无法直接引 file://。对创作者而言，这类工具的卖点是“图片不经手第三方服务器”，但仍需注意密钥加密存储的安全边界由本地环境决定。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

值得关注的后续

一是该系列第 3 篇的踩坑复盘，目前公开信息显示尚未在本次素材中展开；二是流水线在限流、重试等异常场景下的稳定性，文章提到“第2张触发限流，20s 后重试”已作为事件推送到前端时间线；三是 Wails 在 WebView 碎片化上的后续改进，以及这类本地排版 + 云端大模型混合方案是否会成为 AI 桌面工具的主流形态之一。

来源：juejin