优先用 gobindata + json 或 toml 配置文件，配合 os.UserConfigDir() 定位路径；避免 flag、硬编码或 os.Getwd()，确保单文件打包和多平台兼容。
Go 桌面应用该用哪个库存配置？
直接说结论：优先用 gobindata + json 或 toml 文件，配合 os.UserConfigDir() 定位配置路径；别用 flag 或硬编码路径。Go 原生不带 GUI 配置管理，得自己搭一层轻量封装。
常见错误是把配置写死在 ./config.json，一打包成单文件（比如用 upx 或 packr）就找不到；或者用 os.Getwd() 拿路径，结果用户从桌面快捷方式启动时工作目录是家目录，配置被写错地方。
-
os.UserConfigDir()返回平台标准配置目录：~/.config/yourapp/（Linux）、%APPDATA%\YourApp\（Windows）、~/Library/Application Support/YourApp/（macOS） - 避免用
ioutil.WriteFile直接覆盖——应先写临时文件再原子重命名，防止崩溃导致配置损坏 - 如果用
toml，推荐github.com/pelletier/go-toml/v2；它比 v1 更快、零反射、支持结构体标签如toml:"enabled,omitempty"
如何安全读写 JSON 配置并处理字段变更？
JSON 本身不支持注释、字段缺失易 panic，但胜在通用。关键不是“怎么解析”，而是“怎么让升级不炸”。比如 v1 配置有 "theme": "dark"，v2 加了 "font_size"，老用户更新后不能报错退出。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义配置结构体时，所有字段加
json:",omitempty"，新字段默认值靠 Go 初始化（int是 0，string是""，bool是false） - 读配置前先
os.Stat()判断文件是否存在；不存在就用默认结构体json.MarshalIndent写一份初始配置 - 写入前用
os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)，而不是os.WriteFile——后者在 Windows 上可能因权限失败 - 如果字段语义变了（比如
"timeout_sec"改成"timeout_ms"），在UnmarshalJSON方法里手动兼容，别指望库自动转
GUI 框架（Fyne / Walk）里怎么同步配置变更？
Fyne 和 Walk 本身不监听文件变化，配置改了界面不会自动刷新。你得自己加逻辑，否则用户点完“保存设置”没反应，会以为程序卡了。
典型做法：
- 在保存配置后，显式调用 UI 更新函数，比如
myWindow.SetTitle(cfg.AppName)或themeSelector.SetSelected(cfg.Theme) - 不要用 goroutine 监听文件（
fsnotify），桌面应用配置极少被外部修改；主动同步比被动监听更稳、更省资源 - Fyne 的
fyne.Settings()只管 DPI/字体等系统级设置，**不存你的业务配置**，别混淆 - 如果用了 Walk 的
property绑定，记得在配置加载后调用prop.Set(value)触发界面更新，否则绑定只是摆设
打包成单文件后配置路径还对吗？
对。只要没用 os.Getwd() 或相对路径拼接，os.UserConfigDir() 就不受打包影响——它查的是当前用户，不是可执行文件位置。
容易踩的坑：
- 用
embed.FS把默认配置模板打进二进制，运行时复制到UserConfigDir()下，而不是每次从 embed 里读——否则用户改了配置下次启动又重置 - 某些打包工具（如
goupx）会改变os.Executable()返回值，但UserConfigDir()不依赖它，所以放心 - macOS 上签名后若提示“无法打开”，不是配置问题，是 Gatekeeper 权限；配置目录本身仍是
~/Library/Application Support/YourApp/，别误以为要切到Container目录
最常被忽略的一点：Windows 用户习惯双击 exe 启动，此时 os.Getwd() 是桌面路径，而 UserConfigDir() 返回的是 %APPDATA%，两者完全无关——只要坚持用后者，就不用操心启动方式。
