去年年底我接了个需求：把团队内部一直在用的 AI 翻译辅助工具从网页搬到 Windows 桌面上，要求开箱即用、双击就能跑、还得看着像个正经软件。我第一步想到的是 Electron，但看着动辄两三百 MB 的安装包和内存占用，实在下不去手。后来花了几个晚上把 Wails v2 摸了一遍，用 Go + Vue3 重写，最终产物是一个 7MB 多的单个 exe，跑起来内存占用不到 Electron 的零头。这篇就以我实际做完的一个 AI 对话翻译应用为例，把从选型、初始化、前后端通信、对接大模型 API、流式输出到打包发布的全过程讲一遍，里面穿插的全是我踩过的坑和验证过的方案。如果你正打算用 Go 写桌面应用，或者想把网页端 AI 功能迁到桌面，这篇文章应该能帮你省下不少摸索时间。

1. 为什么选 Wails v2：先看清桌面应用的技术账

1.1 桌面跨平台方案选型对比

做桌面应用，主流路子其实就四条：Electron、Tauri、Qt 系、Wails。我简单说说我的判断过程。

Electron 胜在生态成熟，Chromium 整套搬进来，网页代码几乎零改造，但代价是安装包轻松突破 150MB，内存吃 300MB 是常态。Tauri 这几年势头很猛，用 Rust 写后端，前端让系统 WebView 渲染，体积小、性能好，但问题也很现实——团队里没人熟 Rust，光是为了编译过几道生命周期的坎就够喝一壶。Qt 系（C++/Python 绑定）做原生应用质量高，但 UI 开发和前端团队协作起来成本高，Vue3 的组件化优势发挥不出来。

Wails v2 的思路和 Tauri 类似，也是用系统 WebView 渲染前端，但后端语言是 Go。这个对我来说是决定性优势：团队本来就写 Go 服务，程序员成本和维护成本都低；构建产物能打进单个 exe 里，Windows 下基本只有几 MB 到十几 MB；内存占用大概在 40-80MB 区间，比 Electron 小一半以上。虽然它没做到 Tauri 的极致轻量，但对于"用 Go 做点真正有用的桌面工具"这个场景，Wails v2 的工程化完善度和上手成本之间的平衡是最好的。

1.2 Wails 的核心机制：绑定不是 IPC

Wails v2 的前后端通信方式和 Electron 完全不一样。Electron 走的是进程间通信（IPC），主进程和渲染进程通过 channel 传递消息，还要自己约定协议格式，写多了真的很累。Wails 用的是一个叫 binding（绑定）的机制：你在 Go 里定义一个结构体，把它注册给 Wails 运行时，前端 JavaScript 就能直接调用这个结构体上的方法，就像调用本地函数一样。

举个例子，Go 侧写一个GreetService，注册后前端直接await window.go.services.GreetService.Greet(name)，参数会自动完成 JSON 序列化，返回的 Promise 会自动包裹 Go 方法的返回值和 error。整个过程不需要手动定义消息协议、不需要处理路由表、不需要做异步回调配对，数据流是天然的"方法调用"形态。

这种设计对 AI 应用特别有用，因为 AI 应用天然是"前端收集输入、后端跑逻辑和请求、再把结果流式吐回前端"的交互模型。绑定机制让两端的职责切得非常干净：Go 负责一切网络请求、数据处理、本地文件读写，Vue3 只负责 UI 和状态管理。

1.3 这套组合适合做什么样的 AI 应用

我做完这个项目后有个很直观的感受：Wails + Vue3 + AI 这个组合特别适合做工具型 AI 应用，而不是娱乐型或社交型应用。

具体来说，适合做这几种：本地知识库问答工具（数据文件放本地，Go 负责读取和索引）、AI 翻译助手（像我做的那种，桌面应用天然比网页适合高频切换场景）、代码片段生成与管理工具（结合本地文件系统）、日志分析工具（Go 处理大文件，AI 做总结）、以及任何需要"常驻桌面 + 快捷唤起"的工具。

不太适合的场景是：对 UI 动画和复杂视觉效果要求极高的应用（WebView 性能天花板摆着），以及需要调用特别底层系统能力的应用（那还是老老实实上原生）。做这类工具应用的时候，Wails v2 的体验是最爽的——Go 的标准库加上极强的第三方生态，HTTP 请求、文件处理、数据库、甚至嵌入式模型推理，全都能干干净净地封装在后端。

2. 环境准备与项目初始化：动手前的一顿操作

2.1 三件套环境：Go、Node、WebView2

Wails v2 需要三个基础环境，缺一不可。

首先是 Go，建议装 1.21 或更高版本。我用的 1.22，主要是贪图泛型和标准库增强带来的省心。Windows 下装完 Go 记得检查环境变量，go version能跑通就行。

然后是 Node.js，前端构建要用的，Wails 模板里 Vue3 + Vite 的工程跑起来需要 16 以上的版本。我实测 v19 和 v20 都没问题，Vite 部分旧版本对 Node 版本不敏感，这倒不用太纠着。

第三件在 Windows 上尤其重要：WebView2 Runtime。Wails 在 Windows 上的渲染核心是微软的 WebView2（基于 Edge Chromium），Win11 和较新版本的 Win10 一般已经预装，但老机器不一定有。检查方法很简单，打开"控制面板-程序和功能"，看有没有 Microsoft Edge WebView2 Runtime 这一条。没有的话去微软官网装常驻版（Evergreen Standalone Installer），装一次以后自动更新，一劳永逸。这个坑我在后面打包章节会再细讲。

装完三件套，跑一下wails doctor核对环境，它会直接告诉你缺什么，很省心。

2.2 用 wails init 初始化 Vue3 模板

Wails 有内置的项目模板，前端框架直接给你选好。我实际操作是这样的：

# 安装 Wails CLI go install github.com/wailsapp/wails/v2/cmd/wails@latest # 初始化一个带 Vue3 模板的项目 wails init -n aitrans -t vue

这里-n是项目名，-t是模板名字。vue模板默认给的是 Vue3 + JS + Vite，不带 TypeScript。如果你想上 TS，第三方的vue-ts模板也可以，但 Wails 后续官方对 TS 的支持一直在完善，我建议从 JS 起步，先把核心链路跑通，再回头看类型这块。

初始化完成后，进入项目目录，执行：

wails dev

它会自动完成两件事：先编译 Go 后端，再启动 Vite 开发服务器，然后把 WebView2 窗口打开给到http://localhost:34115的前端地址。整个流程窗口会自动弹出的，不需要手动另开浏览器，这一点和 Electron 的electron .体验差不多，属于开了就能跑。

2.3 看懂 Wails v2 默认目录结构

初始化的项目结构长这样：

aitrans/ ├── main.go ├── go.mod ├── go.sum ├── app.go ├── build/ │ ├── appicon.png │ ├── windows/ │ │ ├── icon.ico │ │ └── info.json │ └── ... └── frontend/ ├── package.json ├── vite.config.js ├── index.html ├── src/ │ ├── main.js │ ├── App.vue │ └── components/ └── wailsjs/ ├── go/ └── runtime/

main.go是 Wails 的入口，负责创建应用实例和注册服务。app.go是默认生成的一个示例服务，里面有一个Greet方法。frontend/wailsjs这个目录很特殊，它并不是手写的，而是wails dev或wails build时自动生成的，里面放着前端调用 Go 方法的桥接代码和 Wails 运行时 API 的封装。build/目录则管着打包相关的东西，图标、manifest、安装包配置都在里面。

我建议你初始化后先动两个地方：一是把app.go里的示例方法改造成你自己的业务服务，二是把frontend/src里的示例界面删掉换成你自己的布局。不要纠结于模板自带的那些样式和文件名，它只是脚手架。

3. 核心细节解析：Go 后端与 Vue3 前端如何正确通信

3.1 绑定机制与 window.go 调用链

Wails v2 里，把 Go 方法暴露给前端就两个步骤：定义结构体、注册到wails.Run。

// main.go func main() { err := wails.Run(&wails.Options{ Width: 1024, Height: 768, Bind: []interface{}{ &app.ChatService{}, }, }) if err != nil { println("Error:", err.Error()) } }

上面前端代码调用的路径，就取决于结构体的名字和方法的导出名。假设结构体名字叫ChatService，方法叫SendMessage，那前端访问路径就是：

// 前端代码 const result = await window.go.app.ChatService.SendMessage(content)

注意这里路径里的app哪来的？其实是 Go 包名，app.go如果在app这个 Go 包里，Wails 自动在路径里带上包名app。所以如果你把服务定义在别的包下，前端路径要跟着换。这点容易搞混，我一开始就没绕过来。

还有个大细节：只有导出的方法（首字母大写）才能被前端调用，小写开头的私有方法会被 Wails 忽略。这跟 Go 的导出规则一致，所以你的服务里要把对外暴露的方法名全部首字母大写。

另外，前端的window.go对象在wails dev启动时就已经注入，但在普通浏览器打开前端页面的时候是不存在的。所以不要直接在浏览器里调试窗口环境特有的代码，一定要在 Wails 窗口里跑。

3.2 事件系统：用 Events 做流式推送

绑定解决的问题是从前端到 Go 的调用方向。但 AI 对话场景还有反向需求：Go 在后台接收大模型 API 的流式响应，需要一段一段地推给前端。这时候就得用 Wails 的事件系统。

Go 侧发送事件的方法：

import ( "github.com/wailsapp/wails/v2/pkg/runtime" ) func (s *ChatService) StreamMessage(ctx context.Context, message string) { // 在处理过程中，多次向前端推送增量内容 runtime.EventsEmit(ctx, "chat:stream", map[string]interface{}{ "delta": chunkText, "done": false, }) // 最终推送完成事件 runtime.EventsEmit(ctx, "chat:stream", map[string]interface{}{ "delta": "", "done": true, }) }

前端监听事件的方法：

import { EventsOn } from "../wailsjs/runtime/runtime"; // 在组件挂载时注册监听 EventsOn("chat:stream", (data) => { if (data.done) { // 收尾逻辑 } else { // 把 delta 追加到当前消息 } });

这套事件机制解决了一个我在 Electron 里要写大量样板代码的问题，在 Wails 里直接内置。但要提醒一句：事件监听器要在组件销毁时主动解绑，EventsOff，否则页面来回切换的时候会出现"幽灵监听"，事件多次触发同一个回调，导致 AI 回复内容重复拼接。这个坑我踩得很惨，下决心在代码里严格管理监听生命周期。

3.3 后端代理 AI 请求，绕开 CORS 与密钥泄露

这是整个项目里我强烈建议所有人做的架构决策，不管前端后端多简单，都不要让前端直接调大模型 API。

第一是密钥安全。网页前端和桌面前端本质相同，只要能进 Web 环境，用户就能打开控制台看网络请求，把写在 JavaScript 里的 API Key 拿走。放在 Go 后端里，密钥不出进程，安全性高一个数量级。

第二是 CORS 问题。浏览器里直接跨域请求api.anthropic.com或 OpenAI 接口大概率触发 CORS 拦截，Wails 的 WebView2 环境同样受限。让 Go 后端发起请求，等于彻底绕开了 WebView 的 CORS 限制。

所以我的整体架构就是：Vue3 只管界面和交互，把用户消息通过绑定方法传给 Go；Go 负责拼装请求体、携带 API Key、发给模型服务商，再把返回内容推回来。前端永远接触不到密钥，CORS 也不再是问题。

3.4 设计 Vue3 侧的状态管理

前端我建议把对话状态管理集中起来，不要散落在组件里。我用了最朴素的方式，一个createStore的组合式 API 方法，没有引入 Pinia，因为桌面应用的状态量实在不大，引入重量级状态库反而是负担。

对话页面的核心状态无非三块：消息列表messages、当前输入inputText、是否在生成中isStreaming。需要特别注意的是isStreaming这个状态，它要控制输入框禁用、发送按钮显示加载、以及流式回调是否能追加内容。我在阅读流式事件时通过判断isStreaming来防止用户连续点发送，等生成完毕再置回可用状态。

另一个要点是消息列表渲染性能。虽然 WebView2 的处理能力还行，但长对话场景下直接渲染几千条消息节点会有卡顿，我在实现里做了一层简单的虚拟滚动，只渲染可视区域前后的消息，整体流畅度立刻不一样了。这部分内容在实操章节里再展开。

4. 实操过程：从零实现一个可对话的 AI 翻译助手

接下来进入正题。我以一个真实的 AI 翻译助手为例讲完整实现链路。这个工具的使用场景是：用户输入一段中文或英文文本，选择目标语言，AI 模型翻译结果以流式方式实时显示；同时保留多轮对话上下文，可以针对翻译结果提问，比如"为什么这里的 terminology 不能直译"。

4.1 定义 Go 侧 ChatService 的核心结构

先看服务结构体定义。我把大模型 API 调用相关配置放在结构体字段里，避免到处定义全局变量：

package app import ( "context" "os" ) type ChatService struct { ctx context.Context apiKey string apiBase string model string } // NewChatService 构造函数 func NewChatService() *ChatService { return &ChatService{ apiKey: os.Getenv("AI_API_KEY"), // 建议从环境变量读取 apiBase: os.Getenv("AI_API_BASE"), // 兼容 OpenAI 规范的接口地址 model: "gpt-4o-mini", // 默认模型 } } // Init 生命周期回调，Wails 会在应用启动时调用 func (s *ChatService) Init(ctx context.Context) { s.ctx = ctx }

强调一下apiKey从环境变量读，或者做成配置文件加密存储，不要硬编码在 Go 源码里。这样至少不会一瞪眼就看到密钥。有人可能会问，环境变量在桌面应用里怎么设？可用的办法：在系统环境变量里配置、启动脚本先注入、或者用一个小配置文件读进来。我采用的是配置文件 + 用户首次启动时引导填写，这样对普通用户更友好，同时文件权限设为当前用户可读写。

接下来看绑定方法的入口，前端调用SendMessage就进到这里：

type ChatRequest struct { Messages []Message `json:"messages"` TargetLang string `json:"targetLang"` } type Message struct { Role string `json:"role"` Content string `json:"content"` } func (s *ChatService) SendMessage(req ChatRequest) (string, error) { // 直接返回完整结果，适合短文本翻译 reply, err := s.complete(req.Messages, req.TargetLang) if err != nil { return "", err } return reply, nil }

对于只要求整段返回的场景，发一次普通 HTTPS 请求拿完整返回就够了。流式输出放在另外一个方法里，因为流式推送是异步事件驱动的，不能依赖绑定方法的返回值。后面几节会专门讲流式实现。

4.2 对接大模型 API：组装请求与 SSE 流式转发

大模型的 HTTP 接口现在基本都兼容 OpenAI 的规范，POST /v1/chat/completions，JSON body 里带model、messages、stream，响应是 SSE 格式的text/event-stream。

Go 标准库的net/http完全够用，不需要引入 OpenAPI 官方 SDK，这样反而少一层依赖、少一层适配成本。核心代码：

func (s *ChatService) stream(ctx context.Context, messages []Message) error { payload := map[string]interface{}{ "model": s.model, "messages": messages, "stream": true, "temperature": 0.3, // 翻译场景温度调低，减少创造性发挥 } body, _ := json.Marshal(payload) req, _ := http.NewRequestWithContext(ctx, "POST", s.apiBase+"/v1/chat/completions", bytes.NewReader(body)) req.Header.Set("Content-Type", "application/json") req.Header.Set("Authorization", "Bearer "+s.apiKey) resp, err := http.DefaultClient.Do(req) if err != nil { return err } defer resp.Body.Close() scanner := bufio.NewScanner(resp.Body) for scanner.Scan() { line := scanner.Text() if !strings.HasPrefix(line, "data:") { continue } data := strings.TrimSpace(strings.TrimPrefix(line, "data:")) if data == "[DONE]" { break } var chunk struct { Choices []struct { Delta struct { Content string `json:"content"` } `json:"delta"` } `json:"choices"` } if err := json.Unmarshal([]byte(data), &chunk); err != nil { continue } if len(chunk.Choices) > 0 { delta := chunk.Choices[0].Delta.Content if delta != "" { // 推送给前端 runtime.EventsEmit(s.ctx, "chat:stream", map[string]interface{}{ "delta": delta, "done": false, }) } } } runtime.EventsEmit(s.ctx, "chat:stream", map[string]interface{}{ "delta": "", "done": true, }) return nil }

这段代码里有两个细节值得琢磨。

第一个是temperature参数。做翻译任务我设到 0.2-0.3，因为翻译要的是忠实，不是创意；做"润色文案"或"头脑风暴"类任务就会调高到 0.7 左右。温度越低，模型每次输出的差异越小，这个参数直接决定 AI 服务的"人设"，建议在界面上做成可调节选项，默认值按场景预置。

第二个是bufio.Scanner的单行长度限制问题。bufio.Scanner默认最大 token 是 64KB，如果某些平台 API 的 SSE 单行长度大（比如一条带完整系统提示的 event 异常长），会报bufio.ErrTooLong。稳妥做法是初始化时设置更大的 buffer：

scanner := bufio.NewScanner(resp.Body) scanner.Buffer(make([]byte, 1024), 1024*1024)

这段代码我踩过坑。某次对接一个 API 网关，它把多段 JSON 合并成一行返回，单行超过了 64KB，前面的流式没问题，到一半时报错终止。排查了整整一晚上才发现是这个 scanner buffer 的锅。所以直接写大 buffer 保平安。

4.3 前端对话交互：处理流式输出与消息状态

Vue3 侧我用了组合式 API 写业务逻辑，集中在一个useChat组合函数里。核心实现如下：

import { ref } from "vue"; import { EventsOn, EventsOff } from "../../wailsjs/runtime/runtime"; export function useChat() { const messages = ref([]); const isStreaming = ref(false); let streamHandler = null; function registerStreamListener() { if (streamHandler) return; streamHandler = (data) => { if (data.done) { isStreaming.value = false; // 标记当前消息已结束 if (messages.value.length > 0) { messages.value[messages.value.length - 1].done = true; } } else { // 关键：直接向最后一条消息追加增量 const last = messages.value[messages.value.length - 1]; if (last) { last.content += data.delta; } } }; EventsOn("chat:stream", streamHandler); } function unregisterStreamListener() { if (streamHandler) { EventsOff("chat:stream"); streamHandler = null; } } async function send(text, targetLang) { if (isStreaming.value) return; isStreaming.value = true; // 先插入用户消息和空的 AI 消息占位 messages.value.push({ role: "user", content: text }); messages.value.push({ role: "assistant", content: "", done: false }); // 调用 Go 绑定方法 const result = await window.go.app.ChatService.SendMessage({ messages: messages.value, targetLang: targetLang, }); // 如果服务端走的非流式返回，这里拿到完整结果 const last = messages.value[messages.value.length - 1]; if (last && !last.done) { last.content = result; last.done = true; } isStreaming.value = false; } return { messages, isStreaming, send, registerStreamListener, unregisterStreamListener }; }

用的时候在组件onMounted注册监听，onUnmounted解绑，一进一出保证生命周期干净。

这里有个前端设计的小心得：流式推送时，我用了一个空内容的 assistant 消息占位，收到 delta 就往后追加。这样做的好处是界面上的打字机效果可以直接依赖messages数组的最后一个元素，不需要额外维护临时变量。而且一旦用户中途想停止（比如模型跑偏了），直接调用 Go 暴露的StopStream方法由后端取消 HTTP 请求，清掉占位消息，状态立刻回到可控状态。

4.4 参数选择：模型、温度、上下文窗口的取舍

模型选择上我没有盲目冲大模型，实际做了三档配置。默认档用gpt-4o-mini这类小模型，应对大多数翻译和问答足够，速度快而且 token 成本低。高精度档切到gpt-4o或国产大模型的旗舰模型，适合长文档翻译或专业术语多的文本。轻量档用更小的模型跑短句翻译，延迟能压到几百毫秒。

温度参数按照任务场景做预设：翻译类 0.2，总结类 0.4，创意写作类 0.8。我实现里做成了三档按钮，界面上一个滑杆直接调，用户改完保存在本地配置里，下次启动自动加载。

上下文窗口这块容易走极端。有人把所有历史消息全发给模型，很快就顶到 token 上限；有人一概只发当前一条，多轮对话的上下文关联又没了。我的做法是：后端维护消息仓库，但发送上游时只取最近 10 条消息，并且把系统提示词、当前翻译约束放在开头。这样既保留了多轮语境，又把 token 消耗控制在一个稳定的量。更重要的是系统提示词要精心设计——翻译助手这类任务，我明确写"只输出翻译结果，不要解释也不要添加额外说明"，这样能避免模型絮絮叨叨给出"好的，以下是翻译：……"这种废话。

5. 打包发布与常见问题排查实录

5.1 wails build 打包流程与主程序命名

开发调试跑通之后，发布前的打包操作很简单：

wails build -production -trimpath -o AITrans.exe

-production会做前端代码的生产构建和混淆，-trimpath可以缩小 Go 二进制的路径信息，-o指定输出的产物名。默认产物在build/bin/目录下。

但如果你只跑这一步，大概率会在 Windows 上遇到程序无法启动或者启动后白屏的问题。原因多半在 build 配置。Wails 的产物依赖几个关键文件：

• 一个合法的 exe 图标。如果build/windows/icon.ico还是模板默认图标，构建出来的 exe 会很小而且没有图标，有些安全软件会怀疑这种"无图标、无版本信息"的执行文件。建议早早在build/appicon.png放好你的正式 Logo，Wails 构建时会自动转换成 ico。
• 版本信息文件windows/info.json。这里面写着公司名、产品名、版权等字段，不填的话右键 exe 的文件属性一片空白，很影响分发信任度。我把里面信息补齐之后，至少在客户现场会少很多"这软件靠谱吗"的质疑。

还有一个关键点：wails build默认打出来的 exe 是给当前系统架构的，x64 就是这样，不要想着一个 exe 通吃 32 位和 64 位。Windows 早该淘汰 32 位了，但如果你要照顾老机器，可以在构建时加-platform windows/386，前提是 WebView2 在 32 位系统上可用（实际上 Win10 32 位也是支持 WebView2 的）。

5.2 换了机器跑不起来？WebView2 运行时排查

开发机上跑得好好的，拷到同事电脑上双击，结果"应用程序无法正常启动"，这个场景我碰到过，原因是目标机器缺少 WebView2 Runtime。

WebView2 是 Wails 在 Windows 上的命根子，没有它窗口根本起不来。新版 Win11 基本自带，但 Win10 老版本或者精简版系统经常没有。解决方式有三种：

一种是在产品分发时带一个 WebView2 Runtime 的 bootstrapper 安装包，安装前检测系统里是否有 WebView2，没有就静默装一遍。官方叫Evergreen Bootstrapper，微软下载中心有离线安装包。用wails build时的 NSIS 安装器配置项里也可以直接指定让它自动下载安装 WebView2。

第二种是写一段 Go 代码，启动时检查注册表里是否已装 WebView2，并给出友好提示。注册表路径是HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}，没有这个键基本就可以认定没装。

第三种干脆装常驻版。如果你不愿意做安装器，就告诉用户先装 WebView2 常驻版再运行程序。但对于普通用户来说"先装一个运行库"的体验还是比"双击直接跑"差不少，有条件都建议做安装器。

5.3 最容易踩的五个坑，我挨个记下来了

先列一个速查表，再逐个展开细节。

第一个坑，wails dev的页面热更新理论上由 Vite 保证，但如果你的 Go 代码或者 Wails 绑定方法改了，那就不是前端热更新的事，得重启wails dev。我习惯是：只改前端组件就不重启，改 Go 服务方法就重跑一遍，省时间也稳定。

第二个坑我在 3.1 节讲过，方法导出这块很容易忘。还有一个小细节：绑定的结构体必须是*ChatService这种指针形式，传值（ChatService{}）会导致方法集不完整，部分方法调不到，这个细节文档里不起眼，但真能困扰人一整天。

第五个坑，体积异常的排查方法就比较直接了。先go version -m exe看内置模块列表，找出哪个模块体积异常，然后检查go.sum里是不是有测试依赖被打进来。正常来说，一个只做 HTTP 请求的 Go 程序打包出来的 exe 应该在 10MB 上下，如果超过 50MB，多半是引入了重量级库。

5.4 满足实际需要的性能优化与体积控制

性能这块我说三个我实际验证过的优化点。

第一是窗口启动速度。Wails 窗口的展示依赖前端资源加载，Vue3 应用如果能做到首屏极小（只渲染一个输入框和一个消息列表），启动速度就很快。我做了按路由和组件的动态引入，首屏只需加载核心几个组件，实测窗口从点击到可交互在普通 SSD 机器上不到 1 秒。

第二是流式渲染的频率控制。模型输出是碎片化的，每个碎片几毫秒就推一次，如果前端每次都触发 Vue 的响应式更新和 DOM 重绘，界面会卡。我在推流端做了缓冲：Go 侧累积一定量的文本（比如每隔 40 毫秒）再 Emit 一次，前端收到的渲染频率降低一个数量级，打字机效果依然平滑但 CPU 占用明显下降。这块我做了个简单的定时刷批逻辑：

// 伪代码：每 40ms 批量推送一次累积的增量 ticker := time.NewTicker(40 * time.Millisecond)

第三是 Go 后端连接复用。http.DefaultClient默认的连接池行为足够好，但要注意不要每次请求都创建一个新的http.Client。用一个全局单例的http.Client并设置合理的超时（比如 30 秒连接超时、响应体空闲超时），能明显减少接口的连接建立开销。这个对桌面应用尤其重要，因为桌面应用存在频繁的短请求，连接池就是命。

另外体积控制上，wails build默认带调试功能的话产物会大一圈，务必用-production。图标和资源文件不要放高清大图，WebView2 需要的 logo 用压缩过的 PNG 就够了，一条资源多几 MB，积少成多就会很夸张。

6. 一些扩展建议：让 AI 桌面应用更接地气

做完这个项目之后，有几个基于实操的扩展方向，我觉得比架构理论更值得说。

如果你想把桌面应用做得更"桌面"，可以接入托盘（system tray）。Wails v2 内置了对系统托盘的支持，在wails.Run里配好Tray选项就能把应用最小化到右下角，点击图标再唤出主窗。对 AI 工具类应用来说，托盘是刚需——用户不会希望翻译工具一直占着任务栏位置。

本地数据持久化我用的是 SQLite（通过modernc.org/sqlite这个纯 Go 驱动，不用 CGO，省了交叉编译很多麻烦）。对话记录、设置项、API Key 全存在本地一个 sqlite 文件里，用户隐私和数据归属都清清楚楚。这对桌面端的价值是 Web 端没有的，至少我做完后给自己用的时候，这个工具就从"演示"变成了"真正在用的东西"。

再进一步，如果你愿意探索，可以用go-llama.cpp这类绑定把本地小模型跑进 Go 进程里，这样应用完全离线可用，对隐私敏感场景非常加分。不过那属于另一个量级的工作量，如果你想把当前这条路跑熟，建议先把"云端 API + 本地管理"这套吃透再考虑。

我个人实际用下来的体会是：Wails v2 最大的价值不在于它打败了谁，而在于它让"用 Go 写桌面应用"变成了一件不需要犹豫的事情。它对 Go 生态的忠实度很高，对前端开发者又足够宽容，通信模型直接、顺手，像给后端程序员的桌面开发补上了最短路径。

最后分享一个收尾小技巧：发布前用虚拟机和另一台完全没有 Go/Node 环境的电脑实测一遍打包产物，确认它真的能双击就跑。桌面应用和 Web 服务不一样，用户拿到的永远是那个"静态产物"，你本地跑得再欢、环境再全都没用，目标机器上的一秒闪退，就是分发的全部真相。我每次发版都是这样自测一遍，这个习惯帮我拦下了至少三次"换台机器就白屏"的事故。