桌面端 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 v21.1 三个方案的真实差异不在能不能做而在代价是什么很多人选桌面框架时只看功能列表觉得三个都能做随便挑一个就行。但真正上手之后你会发现差异体现在三个很实际的地方运行时体积、内存占用、以及前后端语言的心智负担。Electron 自带 Chromium 和 Node.js好处是渲染行为在所有平台上完全一致坏处是打包体积轻松超过 150MB空载内存 200MB 起步。Tauri 用系统 WebView体积小后端是 Rust性能和内存都很优秀但 Rust 的学习曲线对大多数前端或 Go 开发者来说是一道真实的门槛尤其是涉及异步、所有权、生命周期的时候写业务逻辑的效率会明显下降。Wails v2 的定位介于两者之间它同样使用系统 WebViewWindows 上是 WebView2macOS 上是 WKWebViewLinux 上是 WebKitGTK所以体积和内存接近 Tauri后端语言是 Go语法简单、编译快、并发模型清晰对写过一点后端的人来说几乎没有学习成本。下面这张表是我实测下来最直观的对比维度ElectronTauriWails v2打包体积空项目约 150MB约 5-10MB约 8-15MB空载内存约 200MB约 60MB约 70MB后端语言Node.jsRustGo前端自由度任意任意任意官方模板含 Vue/React/Svelte跨平台一致性完全一致依赖系统 WebView依赖系统 WebView学习成本低高低到中这里有个关键点必须说清楚依赖系统 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/wailslatest装完之后把%GOPATH%\bin加到 PATH 里再运行wails doctor。这个命令非常有用它会检查你的环境是否完整包括 WebView2 运行时、Node、npm 等并给出明确的缺失提示。我强烈建议每次环境出问题先跑一遍wails doctor比盲目搜索快得多。macOS 上还需要 Xcode Command Line ToolsLinux 上需要装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.ContextWails 会自动注入你可以用它做取消和超时控制。错误会作为 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) }注意前端调用时不需要传ctxWails 会自动处理。3.2 流式输出为什么不能用绑定方法直接返回AI 应用的核心体验是流式输出——模型一个字一个字地吐界面实时显示。但绑定方法是请求-响应模型调用后要等 Go 函数返回才能拿到结果。如果等整个回复生成完再返回用户会盯着空白界面等好几秒体验很差。所以流式输出必须走事件系统而不是绑定方法的返回值。Wails 提供了runtime.EventsEmit让 Go 主动向前端推送事件前端用EventsOn监听。设计思路是这样的前端调用StartStream(sessionID, content)这个绑定方法它立即返回不阻塞。Go 在后台启动一个 goroutine 去请求模型接口逐块读取响应。每读到一块内容就通过runtime.EventsEmit(ctx, stream:chunk, payload)推给前端。前端监听stream:chunk事件把内容追加到当前消息上。流结束时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 Recordstring, Message[], streaming: new Setstring(), 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-desktopmacOS 上是~/Library/Application Support/ai-desktopLinux 上是~/.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 发送、ShiftEnter 换行。这个用 Vue3 的响应式很容易实现textarea v-modelinput inputautoResize keydown.enter.exact.preventsend keydown.enter.shiftinput \n rows1 /autoResize里把style.height设为auto再设为scrollHeight就能实现自适应。注意要设一个最大高度超过之后出现滚动条否则输入长文本时输入框会撑满整个窗口。7. 打包分发从开发到用户手里还差哪几步7.1 构建命令与产物结构开发完成后运行wails build默认会生成当前平台的可执行文件放在build/bin/目录下。Windows 上是.exemacOS 上是.appLinux 上是可执行文件。如果要指定平台用-platform参数比如wails build -platform windows/amd64。但要注意交叉编译有限制从 macOS 编译 Windows 版本通常可行但涉及 CGO 的依赖会出问题。最稳妥的方式是在目标平台上构建或者用 CI 分别构建。7.2 体积优化从 30MB 压到 15MBWails 默认构建出来的体积已经不大但还能再优化。几个有效的手段第一用-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感受一下它的开发流程。很多时候选型的答案不在对比表里而在你亲手跑通第一个窗口的那一刻。
桌面端 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 v21.1 三个方案的真实差异不在能不能做而在代价是什么很多人选桌面框架时只看功能列表觉得三个都能做随便挑一个就行。但真正上手之后你会发现差异体现在三个很实际的地方运行时体积、内存占用、以及前后端语言的心智负担。Electron 自带 Chromium 和 Node.js好处是渲染行为在所有平台上完全一致坏处是打包体积轻松超过 150MB空载内存 200MB 起步。Tauri 用系统 WebView体积小后端是 Rust性能和内存都很优秀但 Rust 的学习曲线对大多数前端或 Go 开发者来说是一道真实的门槛尤其是涉及异步、所有权、生命周期的时候写业务逻辑的效率会明显下降。Wails v2 的定位介于两者之间它同样使用系统 WebViewWindows 上是 WebView2macOS 上是 WKWebViewLinux 上是 WebKitGTK所以体积和内存接近 Tauri后端语言是 Go语法简单、编译快、并发模型清晰对写过一点后端的人来说几乎没有学习成本。下面这张表是我实测下来最直观的对比维度ElectronTauriWails v2打包体积空项目约 150MB约 5-10MB约 8-15MB空载内存约 200MB约 60MB约 70MB后端语言Node.jsRustGo前端自由度任意任意任意官方模板含 Vue/React/Svelte跨平台一致性完全一致依赖系统 WebView依赖系统 WebView学习成本低高低到中这里有个关键点必须说清楚依赖系统 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/wailslatest装完之后把%GOPATH%\bin加到 PATH 里再运行wails doctor。这个命令非常有用它会检查你的环境是否完整包括 WebView2 运行时、Node、npm 等并给出明确的缺失提示。我强烈建议每次环境出问题先跑一遍wails doctor比盲目搜索快得多。macOS 上还需要 Xcode Command Line ToolsLinux 上需要装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.ContextWails 会自动注入你可以用它做取消和超时控制。错误会作为 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) }注意前端调用时不需要传ctxWails 会自动处理。3.2 流式输出为什么不能用绑定方法直接返回AI 应用的核心体验是流式输出——模型一个字一个字地吐界面实时显示。但绑定方法是请求-响应模型调用后要等 Go 函数返回才能拿到结果。如果等整个回复生成完再返回用户会盯着空白界面等好几秒体验很差。所以流式输出必须走事件系统而不是绑定方法的返回值。Wails 提供了runtime.EventsEmit让 Go 主动向前端推送事件前端用EventsOn监听。设计思路是这样的前端调用StartStream(sessionID, content)这个绑定方法它立即返回不阻塞。Go 在后台启动一个 goroutine 去请求模型接口逐块读取响应。每读到一块内容就通过runtime.EventsEmit(ctx, stream:chunk, payload)推给前端。前端监听stream:chunk事件把内容追加到当前消息上。流结束时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 Recordstring, Message[], streaming: new Setstring(), 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-desktopmacOS 上是~/Library/Application Support/ai-desktopLinux 上是~/.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 发送、ShiftEnter 换行。这个用 Vue3 的响应式很容易实现textarea v-modelinput inputautoResize keydown.enter.exact.preventsend keydown.enter.shiftinput \n rows1 /autoResize里把style.height设为auto再设为scrollHeight就能实现自适应。注意要设一个最大高度超过之后出现滚动条否则输入长文本时输入框会撑满整个窗口。7. 打包分发从开发到用户手里还差哪几步7.1 构建命令与产物结构开发完成后运行wails build默认会生成当前平台的可执行文件放在build/bin/目录下。Windows 上是.exemacOS 上是.appLinux 上是可执行文件。如果要指定平台用-platform参数比如wails build -platform windows/amd64。但要注意交叉编译有限制从 macOS 编译 Windows 版本通常可行但涉及 CGO 的依赖会出问题。最稳妥的方式是在目标平台上构建或者用 CI 分别构建。7.2 体积优化从 30MB 压到 15MBWails 默认构建出来的体积已经不大但还能再优化。几个有效的手段第一用-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感受一下它的开发流程。很多时候选型的答案不在对比表里而在你亲手跑通第一个窗口的那一刻。
