os.UserConfigDir()基本可靠但仅Go 1.13+有效，返回系统规范配置根目录，需手动拼接应用名并调用MkdirAll创建专属子目录，不可直接写入根路径或混用UserHomeDir。
os.UserConfigDir 返回的路径到底靠不靠谱
它基本可靠，但只在 Go 1.13+ 生效，且依赖操作系统原生规范：Linux 走 XDG_CONFIG_HOME 或 $HOME/.config，macOS 用 ~/Library/Application Support，Windows 用 %AppData%。低于 1.13 的版本调用会 panic，不是返回空字符串——这点容易被忽略，直接上线可能崩。
实操建议：
- 务必检查 Go 版本，CI 和构建环境也得统一；
- 不要假设路径一定存在，
os.UserConfigDir()只返回路径，不自动创建目录； - 若需兼容老版本，得手动 fallback 到
os.UserHomeDir()+ 自定义子路径（如filepath.Join(home, ".myapp")）。
为什么不能直接写配置文件到 os.UserConfigDir() 返回的路径
因为该函数只返回根目录，比如 /home/alice/.config，而你的应用需要的是专属子目录，如 /home/alice/.config/myapp。直接往根下写会污染其他应用，也违反 XDG 规范。
正确做法是拼接应用名并确保目录存在：
cfgDir, err := os.UserConfigDir()
if err != nil {
log.Fatal(err)
}
appCfgDir := filepath.Join(cfgDir, "myapp")
if err := os.MkdirAll(appCfgDir, 0755); err != nil {
log.Fatal(err)
}
// 再写 config.json 到 appCfgDir
注意：0755 权限在 Windows 上会被忽略，但显式声明更清晰；MkdirAll 必须调用，否则后续 os.OpenFile 会报 no such file or directory。
和 os.UserHomeDir() 混用时最容易踩的坑
有人图省事，在 macOS 或 Linux 下用 os.UserHomeDir() 拼 .myapp/config.toml，结果在 Windows 上变成 C:\Users\Alice\.myapp\config.toml —— 这既不符合 Windows 用户预期（应落在 %AppData%），也不被杀毒软件信任，还可能因权限问题写入失败。
关键差异点：
-
os.UserConfigDir()是语义化路径，表达“这里放配置”； -
os.UserHomeDir()是物理路径，表达“这是用户家目录”，无约定含义； - 混用会导致跨平台行为不一致，尤其在企业内网或沙盒环境中，
%AppData%可能被重定向，而%USERPROFILE%不会。
要不要在配置路径里加版本号或作者名
要，特别是当配置格式有 Breaking Change 时。例如从 v1 升级到 v2 后，旧版解析器读新配置会出错，但用户又想保留旧配置做迁移。这时可把路径定为 filepath.Join(cfgDir, "myorg", "myapp", "v2")。
不过要注意两点：
- 路径层级越深，
os.MkdirAll开销略增（可忽略，但别嵌套 10 层）； - 如果用了
os.UserCacheDir()或os.UserDataDir()，同样要保持命名策略一致，避免缓存和配置路径错位； - 别把 Git 分支名、构建时间这类动态值塞进路径——这会让调试和清理变得不可预测。
路径一旦选了就别轻易改，哪怕只是加个前缀，都得考虑存量用户迁移成本。最麻烦的不是代码，是用户磁盘上那些散落的 .config/myapp-old 目录。
