go桌面应用无法真正热更新，只能通过go-selfupdate实现无缝重启：下载校验新二进制、替换并重启，需适配各平台签名与自启机制，插件机制不可行，核心难点在于更新时机判断与状态快照恢复。
Go 桌面应用无法真正热更新，所谓“自动更新”本质是「安全替换二进制 + 无缝重启」。你不需要自己实现下载、校验、原子替换和进程接管——go-selfupdate 已覆盖 macOS / Windows / Linux 主流平台，且处理了签名、UAC、自启注册等真实障碍。
为什么不能用 plugin 或 fsnotify 做桌面端热更新
plugin 包在桌面分发场景下基本不可行：plugin.Open() 要求 GOOS/GOARCH、Go 版本、SDK 版本完全一致，而用户环境千差万别；macOS 上不同系统版本的 NSApplication 内存布局变化会导致 panic；Windows 不支持 Go 编译的 .so，DLL ABI 又无保证。同样，fsnotify 在桌面 GUI 应用里会出问题：主进程独占窗口句柄，子进程 fork 后无法继承；Windows 对 OneDrive 同步目录或符号链接事件支持不稳定；更关键的是，用户双击图标启动时工作目录是家目录，filepath.Walk("./") 直接失败。
- 插件机制不是“不推荐”，而是 runtime 层面就卡死——
plugin.Open()失败时不会报明确错误，只静默 panic -
fsnotify仅适用于 CLI 工具或开发期调试，上线后必须移除 - 任何试图在运行中
exec.Command("go", "build")然后exec.LookPath替换自身的做法，都会在 macOS Gatekeeper 或 Windows SmartScreen 下被拦截，且无提示
go-selfupdate 的最小可行配置与关键字段
go-selfupdate 不是“开箱即用”，它依赖你提前约定好服务端返回的 JSON 清单格式，并严格校验字段。最简能跑通的配置如下：
updater := &selfupdate.Updater{
CurrentVersion: "v1.2.3", // 必须是语义化版本，"dev" 或 "1.2.3" 会被跳过
ApiURL: "https://updates.example.com/v1/",
BinURL: "https://updates.example.com/bin/",
DiffURL: "https://updates.example.com/diff/",
Dir: "update/",
CmdName: "myapp",
}
updater.BackgroundRun()
-
ApiURL返回的 JSON 必须含version（字符串）、sha256（完整包哈希）、url（完整二进制路径），可选diff_url -
CurrentVersion若为"dev"，go-selfupdate会直接禁用检查 —— 别用时间戳或 commit hash 代替语义化版本 -
Dir是临时目录，用于存放下载中的文件和状态快照；确保该路径对当前用户可读写，否则更新会静默失败
更新成功后如何安全重启而不丢失状态
调用 os.Exit(0) 并不能保证新进程立即接管。真正的难点在于：GUI 应用有窗口、托盘、IPC 通道等资源，旧进程退出前必须完成状态快照，新进程启动后要恢复。这不是 go-selfupdate 能解决的，得你自己设计。
- 不要在
OnSuccessfulUpdate回调里直接os.Exit(0)—— 应先写入 JSON 快照到os.UserCacheDir()，再 exit - 主程序启动时检查快照文件是否存在，若存在则加载并删除，避免重复恢复
- macOS 上重启后需重新注册自启项：
osascript -e 'launch app "MyApp"'或调用launchctl；Windows 若以服务运行，要用sc start myapp - 如果应用监听本地 IPC（如
unix:///tmp/myapp.sock），旧进程退出前应关闭 listener，新进程启动后再 bind —— 否则新旧实例可能冲突
最易被忽略的点：没有签名的二进制被替换后，在 macOS 或 Windows 上会被系统拦截，且 go-selfupdate 不抛错，只卡在替换步骤。你必须在构建阶段就集成签名流程，而不是把“签名”当作发布后的手动操作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
