json解析报错多因bom或控制字符，需用bytes.trimprefix清理；viper热重载须显式调用watchconfig并注册回调；结构体字段须大写+json tag；优先使用viper.getstring等类型方法而非get。
读取 JSON 配置时 json.Unmarshal 报错 invalid character
大概率是文件开头有 BOM（Byte Order Mark）或混入了不可见控制字符。Windows 编辑器保存 UTF-8 时常悄悄加 BOM，而 Go 标准库的 json.Unmarshal 不跳过它，直接报错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.ReadFile读取原始字节后，先用bytes.TrimPrefix(data, []byte{0xEF, 0xBB, 0xBF})去 BOM - 别依赖编辑器“UTF-8 无 BOM”选项——有些 IDE（如 VS Code）默认仍可能写入；改用命令行确认：
xxd config.json | head -1，看到ef bb bf就是 BOM - 如果配置由前端生成或用户上传，务必在解析前做
bytes.TrimSpace+ BOM 清理
Viper 默认不自动重载 JSON 文件，修改后得手动 viper.WatchConfig()
Viper 的 viper.ReadInConfig() 是一次性加载，哪怕你后续改了 config.json，viper.Get() 返回的仍是旧值。这不是 bug，是设计如此。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启用热重载必须显式调用
viper.WatchConfig()，且需配合viper.OnConfigChange注册回调 - 注意监听路径：Viper 默认监听的是
viper.AddConfigPath()中最后一个路径，不是文件全路径；若配置放在./conf/config.json，要加viper.AddConfigPath("./conf")，再viper.SetConfigName("config") - Linux/macOS 下用 inotify，Windows 下用 fsnotify，但两者对符号链接、NFS 挂载点支持不一；生产环境别依赖热重载做关键配置切换
嵌套结构体字段名没加 json: tag 导致解析为空
Go 结构体字段首字母小写（未导出）或没写 json: tag 时，json.Unmarshal 完全忽略该字段，不会报错，但值永远是零值——这是最隐蔽的坑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有待解析字段必须首字母大写，且显式声明 tag，例如：
Port int `json:"port"` - 如果 JSON 键含下划线（如
db_name），tag 必须匹配：DBName string `json:"db_name"`，不能只靠字段名自动转驼峰 - 用
json.RawMessage延迟解析不确定结构的字段，避免因字段缺失导致整个解包失败
用 Viper 时 viper.Get("server.port") 返回 nil，但 viper.GetString("server.port") 可用
viper.Get() 返回 interface{}，底层实际是 map[string]interface{} 或 float64（JSON 数字统一转成 float64），类型断言容易失败；而 viper.GetString() 等类型方法会自动做类型转换和兜底。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远优先用
viper.GetString()/viper.GetInt()/viper.GetBool()，别自己 castviper.Get()的返回值 - 如果真要处理嵌套 map，用
viper.GetStringMapString("database")这类专用方法，比手动val.(map[string]interface{})安全得多 - 开发期加
viper.Debug()打印当前配置树，确认 key 路径是否拼写正确（比如误写成serer.port）
JSON 配置真正的麻烦不在读取本身，而在字段语义漂移——比如后端加了个新字段，前端没传，或老版本客户端发来旧格式。这时候光靠 json.Unmarshal 或 Viper 的默认行为扛不住，得靠明确的字段校验和默认值兜底。
