Go 语言直接驱动 Electron 窗口是可行的，但不是靠“Electron 原生支持 Go”，而是通过进程间桥接（通常是 WebSocket 或 IPC 封装）实现控制。主流方案中，gotron 和 wails 是两个最常被实际采用的路径，它们定位不同、通信机制不同、维护状态也不同——选错会导致后续调试困难、打包失败或升级断档。
gotron.New() 启动失败：Electron 下载卡住或路径权限报错
gotron 第一次运行会自动下载 Electron 到 .gotron 目录，但它不走 npm registry，而是从 GitHub Releases 拉取二进制。国内网络下极容易卡在 download-electron.sh 阶段，且脚本默认无重试和代理支持。
- 手动预置 Electron：去 Electron 官方 Releases 页面 下载对应平台的
electron-v38.1.2-darwin-arm64.zip（以你项目用的版本为准），解压后把整个electron文件夹放进项目根目录的.gotron/electron/路径下 - 确保
.gotron可写：Linux/macOS 下检查chmod -R u+w .gotron；Windows 下避免放在 OneDrive 或受控文件夹内 - 跳过自动下载逻辑：修改源码中
gotron/download.go的DownloadElectron函数，直接返回 nil（仅限本地开发验证）
wails3 init 创建的项目无法加载前端资源
wails 默认使用 Vite 启动 dev server，但它的 dev 模式依赖 http://localhost:34115（端口由 runtime 动态分配）作为前端入口。如果前端代码里写了硬编码的 fetch("/api/xxx")，而没配 proxy 或 base URL，就会 404。
- 确认
wails.json中"frontend:devserverurl"字段值是否为"http://localhost:34115"（默认值），且未被覆盖 - Vite 项目需显式配置代理：在
vite.config.ts加server.proxy，例如将/api转发到http://localhost:34115/api - 构建时资源路径错误？检查
vite.config.ts的base是否为"./"（非"/"），否则打包后静态资源 404
前后端通信用 WebSocket 还是 IPC？gotron 与 wails 的根本差异
这是最容易混淆的点：gotron 强制走 WebSocket（ws://localhost:PORT/web/app/events），而 wails 在桌面环境下默认走进程内 IPC（类似 Electron 的 ipcRenderer），只有 Web 模式才降级为 WebSocket。这意味着：
- WebSocket 方案（gotron）：前端必须自己建 ws 连接、处理重连、序列化/反序列化 JSON；Go 后端无法直接暴露结构体方法，只能收发
[]byte - IPC 方案（wails）：前端可直接调用
window.backend.MyService.DoSomething({x: 1})，wails 自动完成 Go 结构体 ↔ TypeScript 类型转换，错误也带堆栈 - gotron 已归档不再维护（GitHub 标记为 "archived"），而 wails/v3 活跃更新，对 Apple Silicon、Windows ARM64 支持更稳
真正难的不是启动窗口，而是让 Go 后端能稳定响应前端事件、正确返回结构化数据、并在打包后仍保持通信链路畅通——这些细节在 gotron 的示例里几乎不提，在 wails 文档里则分散在 CLI 日志、runtime 配置和前端 import 路径中。动手前先跑通 wails3 dev 并在浏览器控制台输入 window.backend 看是否挂载成功，比反复改 WindowOptions.Title 有用得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
