Wails v2 + Go + Vue3：构建轻量级AI桌面应用实战

桌面端 AI 应用这件事，我从 Electron 一路折腾到 Tauri，最后在 Wails v2 上停了下来。原因很直接：我想要一个前端能用 Vue3 写、后端能用 Go 写、打包出来体积还能控制在几十兆的桌面程序，而不是一个动辄两百兆起步、内存占用像开了个浏览器的东西。Wails v2 正好卡在这个位置上——它用系统自带的 WebView 渲染前端，用 Go 编译出原生二进制做后端，前后端通过绑定调用和事件系统通信，整个开发体验非常接近写一个本地 Web 服务，但产物是一个双击就能跑的可执行文件。

这篇内容适合两类人：一类是已经会写 Vue3、想把自己的 Web 项目搬到桌面端的开发者；另一类是熟悉 Go、想给命令行工具或后端服务套一个像样界面的工程师。我会用一个"真正能用"的 AI 桌面应用作为主线，把 Wails v2 的项目结构、Go 与 Vue3 的绑定机制、流式输出的处理、本地配置存储、打包分发这些环节全部走一遍，中间穿插我自己踩过的坑和取舍逻辑。读完你应该能独立做出一个能日常使用的桌面 AI 客户端，而不是一个只能跑 Demo 的空壳。

1. 为什么在 Electron、Tauri、Wails 之间我选了 Wails v2

1.1 三个方案的真实差异不在"能不能做"，而在"代价是什么"

很多人选桌面框架时只看功能列表，觉得三个都能做，随便挑一个就行。但真正上手之后你会发现，差异体现在三个很实际的地方：运行时体积、内存占用、以及前后端语言的心智负担。

Electron 自带 Chromium 和 Node.js，好处是渲染行为在所有平台上完全一致，坏处是打包体积轻松超过 150MB，空载内存 200MB 起步。Tauri 用系统 WebView，体积小，后端是 Rust，性能和内存都很优秀，但 Rust 的学习曲线对大多数前端或 Go 开发者来说是一道真实的门槛，尤其是涉及异步、所有权、生命周期的时候，写业务逻辑的效率会明显下降。

Wails v2 的定位介于两者之间：它同样使用系统 WebView（Windows 上是 WebView2，macOS 上是 WKWebView，Linux 上是 WebKitGTK），所以体积和内存接近 Tauri；后端语言是 Go，语法简单、编译快、并发模型清晰，对写过一点后端的人来说几乎没有学习成本。下面这张表是我实测下来最直观的对比：

这里有个关键点必须说清楚：依赖系统 WebView 意味着渲染一致性不如 Electron。比如某些 CSS 特性在不同系统的 WebView 版本上表现会有细微差别，Windows 上如果用户没装 WebView2 运行时还需要额外处理。但对我做的 AI 桌面应用来说，界面主要是聊天列表、输入框、Markdown 渲染，这些用系统 WebView 完全够用，一致性风险可以接受。

1.2 Go 作为后端语言，在 AI 应用场景里到底香在哪

AI 桌面应用的后端要做的事情其实很集中：发 HTTP 请求调用模型接口、处理流式响应（SSE）、读写本地配置文件、管理会话历史、可能还要做本地文件解析。这些任务用 Go 写非常顺手。

第一，Go 的net/http标准库足够强，配合context做超时和取消非常自然。流式响应本质上就是读一个io.Reader，逐行解析data:前缀，这个逻辑用bufio.Scanner几行就能写完。

第二，Go 编译出来是单个静态二进制，没有运行时依赖，用户拿到就是一个 exe，不用装 Node、不用装 Python 环境。这对桌面分发来说是巨大的优势。

第三，Go 的并发模型处理"多个会话同时请求"这种场景很轻松，goroutine 加 channel 就能把流式数据安全地推给前端，不需要像 Node 那样小心翼翼地处理事件循环。

第四，Wails 的绑定机制会把 Go 结构体的方法直接暴露给前端调用，返回值自动序列化成 JSON，错误也能透传。这意味着你写一个func (a *App) SendMessage(msg string) (string, error)，前端就能直接await SendMessage(msg)，中间不需要手写任何 HTTP 路由或 IPC 协议。

1.3 什么情况下我会劝你别用 Wails

不是所有项目都适合 Wails。如果你的应用需要大量依赖浏览器专有 API（比如复杂的 WebRTC、某些硬件访问）、或者需要保证在所有平台上像素级一致的渲染效果、又或者团队里没人愿意碰 Go，那 Electron 可能更省心。Wails 的优势建立在"你愿意用 Go 写后端"这个前提上，如果这个前提不成立，它的很多好处就无从谈起。

另外，Wails v2 的生态相比 Electron 还是小很多，遇到冷门问题时社区答案少，很多时候要自己读源码或翻 GitHub issue。这一点要有心理准备。

2. 环境搭建：从零到跑通第一个窗口

2.1 安装 Wails CLI 与前置依赖

Wails 的安装分两步：先装 Go，再装 Wails CLI。Go 版本建议 1.21 以上，因为 Wails v2 后期版本用到了较新的标准库特性。

在 Windows 上，装完 Go 之后确认go version能正常输出，然后执行：

go install github.com/wailsapp/wails/v2/cmd/wails@latest

装完之后把%GOPATH%\bin加到 PATH 里，再运行wails doctor。这个命令非常有用，它会检查你的环境是否完整，包括 WebView2 运行时、Node、npm 等，并给出明确的缺失提示。我强烈建议每次环境出问题先跑一遍wails doctor，比盲目搜索快得多。

macOS 上还需要 Xcode Command Line Tools，Linux 上需要装libgtk-3-dev和libwebkit2gtk-4.0-dev这些开发库。具体命令wails doctor会告诉你。

2.2 用官方模板初始化项目，但别照单全收

初始化命令是：

wails init -n ai-desktop -t vue-ts

这里我选的是vue-ts模板，也就是 Vue3 + TypeScript。官方还提供vue（不带 TS）、react-ts、svelte等模板。选 TS 的理由很实际：Wails 会自动为 Go 的绑定方法生成 TypeScript 类型声明文件，前端调用时有完整的类型提示和自动补全，写起来不容易出错。

初始化完成后目录结构大致是这样：

ai-desktop/ ├── app.go # Go 应用逻辑入口 ├── main.go # 程序入口，配置窗口选项 ├── wails.json # Wails 项目配置 ├── go.mod └── frontend/ # Vue3 前端 ├── src/ ├── package.json └── vite.config.ts

模板生成的代码能跑，但它是"演示级"的，直接在上面堆业务会很快变乱。我的做法是保留main.go和wails.json的骨架，把app.go拆成多个文件，按职责分目录。后面会详细讲怎么拆。

2.3 开发模式的热重载到底重载了什么

运行wails dev会启动开发模式。这里有个很多人一开始会误解的点：Wails 的热重载对前端和 Go 后端的行为是不一样的。

前端部分由 Vite 驱动，改 Vue 文件会即时热更新，体验和写普通 Web 项目一样。Go 部分则不同——修改 Go 代码后，Wails 会重新编译后端并重启应用，但前端状态会保留。这意味着如果你在 Go 里加了一个新的绑定方法，前端需要重新触发一次绑定生成才能拿到类型提示。

绑定生成是自动的，wails dev运行时会监听 Go 代码变化并重新生成frontend/wailsjs/目录下的绑定文件。如果你发现前端调用新方法报"未定义"，先检查这个目录有没有更新，实在不行重启一次wails dev。

提示：wails dev默认会打开一个带开发者工具的窗口，按 F12 可以调出控制台。生产构建时这些工具会被移除，不用担心。

3. Go 后端与 Vue3 前端的绑定机制，以及 AI 应用的数据流设计

3.1 绑定不是 RPC，理解这一点能少走很多弯路

Wails 的绑定机制经常被误解成"前后端通过 HTTP 通信"。实际上它更接近"前端直接调用 Go 函数"——Wails 在底层用 WebView 的脚本注入能力，把 Go 方法包装成前端可调用的 JS 函数，参数和返回值通过 JSON 序列化传递。

这个机制带来几个重要结论：

• 没有网络开销，调用是进程内的，速度极快。
• 参数和返回值必须是可 JSON 序列化的类型，不能直接传 channel、函数、复杂指针。
• Go 方法的第一个参数如果是context.Context，Wails 会自动注入，你可以用它做取消和超时控制。
• 错误会作为 Promise 的 reject 传回前端，所以前端要用 try/catch 处理。

一个典型的绑定方法长这样：

func (a *App) SendMessage(ctx context.Context, sessionID string, content string) (string, error) { // 业务逻辑 return reply, nil }

前端调用：

import { SendMessage } from '../wailsjs/go/main/App' try { const reply = await SendMessage(sessionID, content) } catch (e) { console.error('调用失败', e) }

注意前端调用时不需要传ctx，Wails 会自动处理。

3.2 流式输出为什么不能用绑定方法直接返回

AI 应用的核心体验是流式输出——模型一个字一个字地吐，界面实时显示。但绑定方法是"请求-响应"模型，调用后要等 Go 函数返回才能拿到结果。如果等整个回复生成完再返回，用户会盯着空白界面等好几秒，体验很差。

所以流式输出必须走事件系统，而不是绑定方法的返回值。Wails 提供了runtime.EventsEmit让 Go 主动向前端推送事件，前端用EventsOn监听。

设计思路是这样的：

1. 前端调用StartStream(sessionID, content)这个绑定方法，它立即返回，不阻塞。
2. Go 在后台启动一个 goroutine 去请求模型接口，逐块读取响应。
3. 每读到一块内容，就通过runtime.EventsEmit(ctx, "stream:chunk", payload)推给前端。
4. 前端监听stream:chunk事件，把内容追加到当前消息上。
5. 流结束时，Go 再发一个stream:done事件，前端做收尾处理。

这里有个关键细节：事件名要带会话 ID 或用 payload 区分会话，否则多个会话同时流式输出时，前端无法判断这块内容属于哪个会话。我的做法是 payload 里带上sessionID，前端根据当前激活的会话决定是否渲染。

type StreamChunk struct { SessionID string `json:"sessionId"` Delta string `json:"delta"` Done bool `json:"done"` } func (a *App) StartStream(ctx context.Context, sessionID string, content string) error { go func() { // 请求模型，逐块读取 for chunk := range streamChan { runtime.EventsEmit(a.ctx, "stream:chunk", StreamChunk{ SessionID: sessionID, Delta: chunk, }) } runtime.EventsEmit(a.ctx, "stream:chunk", StreamChunk{ SessionID: sessionID, Done: true, }) }() return nil }

注意这里用的是a.ctx而不是方法参数里的ctx。a.ctx是应用启动时保存的上下文，事件推送必须用它，否则事件可能发不出去。这个坑我踩过，当时事件死活不触发，排查了半天才发现是上下文用错了。

3.3 前端状态管理：为什么我用 Pinia 而不是组件内 ref

会话列表、当前会话、消息流、流式状态这些东西如果全塞在组件里用 ref 管理，很快就会变成一团乱麻。尤其是流式输出时，事件回调需要修改消息内容，如果状态分散在多个组件，跨组件更新会非常痛苦。

我用 Pinia 建了一个chatStore，集中管理：

• sessions：所有会话的元数据（ID、标题、创建时间）。
• messages：按会话 ID 索引的消息列表。
• streaming：当前正在流式输出的会话 ID 集合。
• activeSessionId：当前激活的会话。

事件监听放在 store 的初始化逻辑里，这样无论哪个组件触发流式输出，状态更新都走同一条路径，逻辑清晰。

import { defineStore } from 'pinia' import { EventsOn } from '../wailsjs/runtime/runtime' export const useChatStore = defineStore('chat', { state: () => ({ sessions: [] as Session[], messages: {} as Record<string, Message[]>, streaming: new Set<string>(), activeSessionId: '', }), actions: { initEventListener() { EventsOn('stream:chunk', (chunk: StreamChunk) => { if (chunk.done) { this.streaming.delete(chunk.sessionId) return } const list = this.messages[chunk.sessionId] if (list && list.length > 0) { list[list.length - 1].content += chunk.delta } }) }, }, })

这里有个性能注意点：流式输出时不要每收到一个字符就触发一次完整的响应式更新。虽然 Vue3 的响应式系统很快，但高频更新仍然会造成不必要的渲染。我的做法是在 Go 侧做一个小缓冲，比如每积累 20-50 毫秒或一定字符数再发一次事件，前端渲染压力会小很多，视觉上也更平滑。

4. 把 AI 能力接进来：请求、流式解析与错误处理

4.1 模型接口调用的基本结构

不管用哪家模型服务，调用方式基本都是 HTTP POST 加 JSON body，流式的话响应是 SSE 格式。Go 里用标准库就能搞定，不一定需要第三方 SDK。

func (a *App) callModel(ctx context.Context, req ModelRequest) (*http.Response, error) { body, _ := json.Marshal(req) httpReq, _ := http.NewRequestWithContext(ctx, "POST", a.endpoint, bytes.NewReader(body)) httpReq.Header.Set("Content-Type", "application/json") httpReq.Header.Set("Authorization", "Bearer "+a.apiKey) client := &http.Client{Timeout: 0} // 流式请求不能设总超时 return client.Do(httpReq) }

这里有个容易忽略的点：流式请求不能设置http.Client的总超时，否则长回复会被中途掐断。正确的做法是用context.WithTimeout控制连接建立和首字节的时间，或者干脆不设超时，靠用户主动取消。我一般给一个较长的 context 超时（比如 5 分钟），并在前端提供"停止生成"按钮，通过取消 context 来中断请求。

4.2 SSE 解析：别自己造轮子，但也别用错轮子

SSE 的格式看起来简单，每行data: xxx，遇到空行表示一个事件结束。但实际解析时有几个坑：

• 数据可能跨多个 TCP 包到达，不能假设一次Read就是一个完整事件。
• 有些服务会在data:后面带空格，有些不带，解析时要兼容。
• 结束标记是data: [DONE]，但不同服务可能不一样。
• 多行 data 需要拼接。

用bufio.Scanner逐行读是最稳妥的方式：

scanner := bufio.NewScanner(resp.Body) scanner.Buffer(make([]byte, 0, 64*1024), 1024*1024) 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 ModelChunk if err := json.Unmarshal([]byte(data), &chunk); err != nil { continue // 单块解析失败不要中断整个流 } // 提取 delta 内容，推给前端 }

scanner.Buffer那行很重要。默认的 Scanner 缓冲区只有 64KB，如果某一行数据特别大（比如模型返回了很长的代码块），会报token too long错误。把上限调到 1MB 能避免这个问题。

注意：单块 JSON 解析失败时应该continue而不是return，因为流式响应里偶尔会有心跳包或格式异常的行，中断整个流会让用户莫名其妙地断掉。

4.3 错误处理要分层次，不能一锅端

AI 应用的错误来源很多：网络不通、API Key 无效、余额不足、请求频率超限、模型返回格式异常、用户主动取消。这些错误如果都笼统地显示"请求失败"，用户根本不知道该怎么办。

我的做法是分三层处理：

第一层是网络层错误，比如context.DeadlineExceeded、连接被拒绝。这类错误提示"网络连接失败，请检查网络后重试"。

第二层是服务层错误，HTTP 状态码非 200。这时候要读取响应体里的错误信息，很多服务会返回结构化的错误 JSON，包含错误类型和描述。把关键信息提取出来展示给用户。

第三层是解析层错误，流式数据格式异常。这类错误通常可以容忍，记录日志即可，不必打断用户。

if resp.StatusCode != http.StatusOK { body, _ := io.ReadAll(resp.Body) var apiErr struct { Error struct { Message string `json:"message"` Type string `json:"type"` } `json:"error"` } if json.Unmarshal(body, &apiErr) == nil && apiErr.Error.Message != "" { return fmt.Errorf("服务返回错误：%s", apiErr.Error.Message) } return fmt.Errorf("请求失败，状态码 %d", resp.StatusCode) }

用户主动取消的情况要单独识别，通过errors.Is(err, context.Canceled)判断，这时候不应该显示错误，而是正常结束流并保留已生成的内容。

5. 本地数据持久化：会话历史与配置怎么存

5.1 为什么我不用数据库，而是用 JSON 文件

会话历史和配置数据量都不大——几百个会话、每个会话几十条消息，加起来也就几 MB。这种量级用 SQLite 有点杀鸡用牛刀，而且引入 CGO 依赖会让交叉编译变麻烦。我直接用 JSON 文件存，简单可靠。

存储位置用 Wails 提供的runtime包获取用户配置目录：

import "github.com/wailsapp/wails/v2/pkg/runtime" func (a *App) getDataDir() string { dir, _ := runtime.Environment(a.ctx).UserConfigDir dataDir := filepath.Join(dir, "ai-desktop") os.MkdirAll(dataDir, 0755) return dataDir }

Windows 上会落到%APPDATA%\ai-desktop，macOS 上是~/Library/Application Support/ai-desktop，Linux 上是~/.config/ai-desktop。用系统标准目录的好处是符合各平台习惯，用户备份或清理时也找得到。

5.2 写入要防丢数据，读入要防崩溃

JSON 文件存储最大的风险是写入过程中程序崩溃导致文件损坏。我的做法是先写临时文件，再原子替换：

func writeJSONAtomic(path string, v interface{}) error { data, err := json.MarshalIndent(v, "", " ") if err != nil { return err } tmp := path + ".tmp" if err := os.WriteFile(tmp, data, 0644); err != nil { return err } return os.Rename(tmp, path) }

os.Rename在同一文件系统内是原子操作，要么成功要么失败，不会出现写了一半的中间状态。这个技巧在处理任何本地持久化时都值得用。

读取时则要容错。如果文件损坏或格式不对，不能让整个应用起不来。我的做法是捕获解析错误，返回空数据并备份损坏文件：

func readJSON(path string, v interface{}) error { data, err := os.ReadFile(path) if os.IsNotExist(err) { return nil // 首次运行，正常 } if err != nil { return err } if err := json.Unmarshal(data, v); err != nil { os.Rename(path, path+".corrupted") return nil } return nil }

5.3 API Key 的存储不能明文

API Key 是敏感信息，直接明文写在 JSON 里不合适。Wails 没有内置的密钥存储，我的做法是用操作系统提供的凭据存储能力，或者至少做一层本地加密。

简单方案是用一个本地生成的密钥对 API Key 做对称加密，密钥存在系统凭据管理器里。复杂方案是直接调用各平台的凭据 API。考虑到跨平台一致性，我倾向于用 Go 的加密库做 AES 加密，密钥派生自机器相关的信息加一个随机盐，盐存在配置文件里。这样即使配置文件被复制到别的机器，也无法解密。

需要说明的是，本地加密只能提高门槛，不能做到绝对安全，因为解密逻辑就在程序里。但对于桌面应用来说，防止明文泄露已经能满足大部分场景。

6. 界面实现：Vue3 在桌面端的几个特殊处理

6.1 窗口拖拽区域和自定义标题栏

桌面应用通常要做无边框窗口加自定义标题栏，这样界面更统一。Wails 在main.go里配置窗口选项：

err := wails.Run(&options.App{ Title: "AI Desktop", Width: 1200, Height: 800, Frameless: true, Windows: &windows.Options{ WebviewIsTransparent: false, }, })

无边框之后，标题栏的拖拽要靠 CSS 的-webkit-app-region: drag。但这里有个坑：拖拽区域内的按钮必须显式设置-webkit-app-region: no-drag，否则按钮点不动，点击事件会被拖拽行为吞掉。

.titlebar { -webkit-app-region: drag; height: 32px; } .titlebar button { -webkit-app-region: no-drag; }

另外，Windows 上无边框窗口会失去系统的最大化、最小化、关闭按钮，需要自己实现。Wails 的runtime包提供了WindowMinimise、WindowToggleMaximise、Quit这些方法，前端直接调用即可。

6.2 Markdown 渲染与代码高亮

AI 回复里大量出现 Markdown 和代码块，渲染质量直接影响使用体验。我用markdown-it做解析，配合highlight.js做代码高亮。

这里有个性能陷阱：流式输出时不要每收到一块就重新解析整个 Markdown。因为 Markdown 解析是 O(n) 的，消息越长，每次重解析的开销越大，几百字之后就会明显卡顿。

我的优化方案是分两阶段渲染：流式进行中，只做简单的文本显示加换行处理，不解析 Markdown；流结束后，再一次性解析成完整 Markdown。这样既保证了流式时的流畅度，又保证了最终显示效果。

如果一定要流式时也渲染 Markdown，可以做一个节流，比如每 200 毫秒解析一次，而不是每块都解析。

6.3 输入框的自动高度和快捷键

聊天输入框需要根据内容自动调整高度，同时支持 Enter 发送、Shift+Enter 换行。这个用 Vue3 的响应式很容易实现：

<textarea v-model="input" @input="autoResize" @keydown.enter.exact.prevent="send" @keydown.enter.shift="input += '\n'" rows="1" />

autoResize里把style.height设为auto再设为scrollHeight，就能实现自适应。注意要设一个最大高度，超过之后出现滚动条，否则输入长文本时输入框会撑满整个窗口。

7. 打包分发：从开发到用户手里还差哪几步

7.1 构建命令与产物结构

开发完成后运行：

wails build

默认会生成当前平台的可执行文件，放在build/bin/目录下。Windows 上是.exe，macOS 上是.app，Linux 上是可执行文件。

如果要指定平台，用-platform参数，比如wails build -platform windows/amd64。但要注意交叉编译有限制：从 macOS 编译 Windows 版本通常可行，但涉及 CGO 的依赖会出问题。最稳妥的方式是在目标平台上构建，或者用 CI 分别构建。

7.2 体积优化：从 30MB 压到 15MB

Wails 默认构建出来的体积已经不大，但还能再优化。几个有效的手段：

第一，用-ldflags "-s -w"去掉符号表和调试信息，通常能减小 20%-30%。

wails build -ldflags "-s -w"

第二，前端构建时开启压缩和 tree-shaking。Vite 默认生产构建已经做了，但要检查有没有引入体积大的库。比如highlight.js全量引入很大，可以只引入需要的语言包。

第三，检查 Go 依赖里有没有引入不必要的包。用go mod why排查可疑依赖。

7.3 用户第一次运行可能遇到的问题

Windows 上最大的问题是 WebView2 运行时。Win10 较新版本和 Win11 自带，但老版本 Win10 可能没有。Wails 支持在安装包里捆绑 WebView2 引导程序，或者检测到缺失时提示用户安装。

macOS 上则是签名和公证问题。未签名的应用在较新系统上会被拦截，提示"无法验证开发者"。正式分发需要 Apple 开发者账号做签名和公证，这一步没有捷径。

Linux 上依赖系统 WebKitGTK，不同发行版版本差异较大，测试时要覆盖主流发行版。

提示：在正式发布前，一定要在干净的虚拟机里测试安装和运行，不要只在开发机上验证。开发机上往往已经装了各种运行时，掩盖了真实用户会遇到的问题。

8. 我在这个项目里踩过的几个真实坑

8.1 事件监听重复注册导致消息重复

开发初期我遇到一个诡异的问题：流式输出时每条消息会显示两遍。排查后发现是EventsOn被注册了两次——一次在 store 初始化时，一次在组件挂载时。Wails 的事件系统不会自动去重，同一个事件名注册多次，回调就会执行多次。

解决办法是把事件监听集中到一处，在应用启动时注册一次，并在组件卸载时用EventsOff清理。如果确实需要在多个地方监听，要确保每个监听都有对应的清理逻辑。

8.2 Go 的 context 用错导致事件发不出去

前面提过，事件推送必须用应用启动时保存的a.ctx，而不是绑定方法参数里的ctx。原因是绑定方法的ctx在方法返回后就失效了，而流式输出是在方法返回后继续在 goroutine 里跑的，这时候用失效的 context 推送事件，事件会静默丢失，不报错也不触发。

这个坑的隐蔽之处在于它不报错，只是"没反应"，很容易误以为是前端监听写错了。我的建议是：所有异步推送事件的地方，统一用a.ctx，形成习惯。

8.3 前端构建产物路径问题

Wails 打包时会把前端构建产物嵌入到二进制里。如果wails.json里的前端路径配置不对，或者前端构建输出目录和配置不一致，打包出来的应用会白屏。

排查方法是在wails dev下一切正常，但wails build后白屏，基本就是路径问题。检查wails.json里的frontend:build和frontend:dist配置，确保和 Vite 的build.outDir一致。

8.4 大文件读写阻塞 UI

有一次我做一个"导入聊天记录"的功能，读取一个几十 MB 的 JSON 文件时，整个界面卡死了好几秒。原因是这个读写在绑定方法里同步执行，而绑定方法运行在主线程上，阻塞期间前端无法响应。

解决办法是把耗时操作放到 goroutine 里，绑定方法立即返回，通过事件通知进度和完成。这个模式和流式输出是一样的思路：任何可能超过 100 毫秒的操作，都不要在绑定方法里同步做。

9. 这套架构还能怎么扩展

走到这里，一个能用的 AI 桌面应用基本成型了。但它的价值不止于此，这套 Go + Vue3 + Wails 的架构可以承载更多东西。

比如本地知识库：用 Go 做文档解析和向量检索，前端做检索结果展示，整个流程都在本地完成，数据不出机器。再比如多模型切换：把不同服务的调用封装成统一接口，前端只关心"发消息"和"收消息"，后端根据配置路由到不同服务。还可以做插件系统：用 Go 的 plugin 机制或者简单的脚本引擎，让用户自己扩展功能。

我个人的体会是，Wails 最大的价值在于它把"桌面应用"这件事的门槛降到了"会写 Web 前端 + 会写一点 Go"的程度。你不需要成为系统编程专家，也不需要跟复杂的构建工具链搏斗，就能做出体积小、启动快、体验接近原生应用的桌面软件。对于独立开发者和中小团队来说，这是一个被低估的选择。

如果你正准备把某个 Web 项目搬到桌面端，或者想给一个 Go 工具做个界面，我建议先花半天时间用 Wails 跑一个最小 Demo，感受一下它的开发流程。很多时候，选型的答案不在对比表里，而在你亲手跑通第一个窗口的那一刻。