选 fyne 适合中等复杂度本地工具，webview 适合已有 Web 界面或需复杂动效；fyne 需注意 Linux 依赖、Wayland 环境变量、macOS 启动方式及 UPX 兼容性，webview 应使用官方维护版本并规避签名问题。
用 fyne 还是 webview？选错框架直接卡死在启动阶段
Go 原生不带 GUI，必须依赖第三方库；目前真正能跨平台、开箱即用且维护活跃的只有 fyne 和 webview 两个主流选择。fyne 是纯 Go 实现的 UI 框架，渲染稳定、API 统一，适合中等复杂度的本地工具；webview（如 webview/webview 或 zserge/webview）本质是嵌入系统 WebView，UI 写 HTML/CSS/JS，适合已有 Web 界面或需要复杂动效的场景。
容易踩的坑：
-
fyne在 Linux 上默认依赖libx11-dev和libgl1-mesa-dev，没装会导致build failed: undefined reference to XOpenDisplay -
webview的zserge/webview已归档，新项目务必用官方维护的webview/webview，否则 macOS 上会因签名问题拒绝运行 - 别用
golang.org/x/mobile/app—— 它只支持 Android/iOS，桌面端根本跑不起来
fyne.NewApp() 启动失败：常见黑屏、闪退、无窗口原因
调用 fyne.NewApp().Run() 后没窗口、终端卡住或立即退出，大概率是事件循环没正确绑定或主 goroutine 提前结束。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保
app.Run()是程序最后执行的语句，前面不能有os.Exit()或 panic 未捕获 - Linux 下如果用 Wayland，需显式设置环境变量：
export FYNE_X11=1（否则可能黑屏） - macOS 上若提示
NSApplication is not running in main thread，说明你用了go run直接执行，必须用go build && ./app启动 - 窗口内容为空？检查是否漏了
w.ShowAndRun()，而不是只调用w.Show()
打包成单文件可执行程序：fyne package 和 upx 的兼容性陷阱
fyne package 默认生成带资源的二进制，但实际分发时往往要压缩体积。这时候有人会顺手加 upx，结果在 macOS 上双击打不开、Linux 上报 cannot execute binary file。
原因很直接：UPX 压缩会破坏 macOS 的代码签名和 Linux 的 ELF 入口段对齐，而 fyne 的资源绑定逻辑依赖原始二进制结构。
正确做法：
- macOS 必须用
fyne package -os darwin -appID your.app.id生成 .app 包，再用codesign签名，不能 UPX - Linux 可以用
upx --best --lzma，但仅限于静态链接构建（CGO_ENABLED=0 go build），否则动态库路径会被混淆 - Windows 上
fyne package -os windows生成的 .exe 已含图标和 manifest，UPX 后图标丢失是常态，不建议压
想调用系统命令或读写用户目录？os.UserHomeDir() 和 exec.Command 的权限盲区
桌面应用常要打开用户文档、调用 git 或导出文件到 Downloads，但 Go 的 os 和 exec 在不同平台行为不一致。
关键细节：
-
os.UserHomeDir()在 macOS/Linux 返回正确路径，但在 Windows 的某些企业环境（启用了“重定向用户文件夹”）可能返回空或错误路径，建议 fallback 到os.Getenv("USERPROFILE") -
exec.Command("open", path)（macOS）或exec.Command("xdg-open", path)（Linux）必须传绝对路径，相对路径大概率失败 - Windows 上用
exec.Command("cmd", "/c", "start", "", path)，注意中间那个空字符串参数——缺了它，start会把 path 当作窗口标题，而不是目标路径 - 所有 exec 调用建议加
.Run()而非.Start()，避免子进程变成孤儿，尤其在 fyne 窗口关闭后还在后台跑着
GUI 和系统交互的边界比想象中薄：一个路径没转绝对、一个环境变量没兜底、一次签名漏掉，用户点开就是白屏或报错。这些地方没法靠“写完再测”覆盖，得从第一行代码就按平台拆分支配。
