json.Unmarshal 静默失败源于结构体与JSON不匹配：字段名大小写、类型、嵌套层级不符时返回零值而不报错；需确保字段导出、正确使用json标签、指针/omitempty处理可选字段、避免map[string]interface{}、拆分嵌套结构体、检查os.ReadFile和json.Unmarshal错误、分离JSON解析与环境变量覆盖逻辑。
配置文件结构不匹配时，json.Unmarshal 会静默失败
Go 的 json.Unmarshal 不会报错就跳过字段，而是严格按结构体字段标签和类型匹配。如果 JSON 字段名与结构体字段名不一致、类型不兼容（比如字符串写成数字）、或嵌套层级错位，解析结果可能是零值，且无明显提示。
常见现象：读取后字段全是默认值（0、""、nil），但程序不 panic，也不报错。
- 确保结构体字段首字母大写（否则无法导出，
json包无法访问） - 用
json:"field_name"标签显式指定键名，大小写必须完全一致（JSON 是大小写敏感的） - 对可选字段，用指针或
omitempty标签，避免类型强制转换失败（如"timeout": null对应int字段会出错） - 调试时先打印原始字节（
fmt.Printf("%s", data)），确认 JSON 内容符合预期
嵌套对象和数组字段容易漏掉结构体定义
JSON 中的 object 和 array 必须对应 Go 中的 struct 或 slice，不能直接用 map[string]interface{} 或 []interface{} —— 虽然能解析，但后续取值麻烦、类型断言易 panic，且 IDE 无法补全。
例如：{"db": {"host": "localhost", "port": 5432}, "features": ["auth", "cache"]}
立即学习“go语言免费学习笔记（深入）”；
-
db应该定义为独立结构体（如DBConfig），而不是map[string]interface{} -
features声明为[]string，而非[]interface{}；若不确定长度或内容，可用*[]string处理 null 场景 - 嵌套太深时，建议拆分结构体并用内嵌（
type Config struct { Server ServerConfig `json:"server"` }），提升可读性和测试性
文件读取后忘记检查 os.Open 和 json.Unmarshal 的错误
这两个地方最容易被忽略：前者可能因路径错、权限不足失败；后者可能因格式非法（多逗号、单引号、Unicode BOM）导致解析中断，返回非 nil 错误。
- 不要只检查
err != nil就 panic，应区分错误类型（如os.IsNotExist(err)可提示用户检查路径） -
json.Unmarshal错误信息通常含行号（如invalid character '}' looking for beginning of object key string），可直接定位 JSON 语法问题 - 推荐组合使用：
data, err := os.ReadFile("config.json")（Go 1.16+），比os.Open+io.ReadAll更简洁
环境变量与 JSON 配置混合时，别在解析阶段做覆盖逻辑
很多人想“JSON 设默认值，环境变量覆盖”，但在 json.Unmarshal 后硬编码覆盖字段，会导致逻辑分散、难以测试、且破坏结构体字段的语义一致性。
- 把配置加载拆成两步：先解析 JSON 到结构体，再用专门函数（如
ApplyEnvOverrides(&cfg)）统一处理环境变量 - 环境变量键名建议加前缀（如
APP_DB_HOST），避免和系统变量冲突 - 对布尔字段，环境变量建议接受
"true"/"false"或"1"/"0"，用strconv.ParseBool而不是直接比较字符串
真正难的不是解析本身，而是让配置结构能随业务演进 —— 字段增删、类型变更、向后兼容，这些都需要在结构体定义和测试里提前考虑。
