结构体字段必须首字母大写才能被json.Unmarshal解析，小写字段始终为零值；对接snake_case需用json标签桥接；可选字段应使用指针类型；动态字段推荐json.RawMessage；校验须依赖validator库而非仅靠标签。
结构体字段必须首字母大写，否则解析永远为零值
这是最常被忽略的硬性规则：json.Unmarshal 和 json.NewDecoder.Decode 只能设置导出字段（即首字母大写）。小写字段如 port、dbHost 不管标签怎么写，解析后始终是零值，且不报错。
常见错误写法：port int `json:"port"` → 解析后 port 永远是 0，你以为配置加载成功了，其实没加载。
- 正确写法：字段名必须大写，如
Port int `json:"port"` - 对接 snake_case API 时，用标签桥接即可：
DBHost string `json:"db_host"` - 想彻底排除某字段参与解析？加
json:"-"标签，比注释掉更可靠
可选字段要用指针，否则无法区分“未提供”和“零值”
比如配置文件里没写 "timeout" 字段，你希望知道它是缺失，而不是默认设成 0（这可能被误认为用户显式设置了 0 秒超时）。
int、string、bool 这类类型在字段缺失时都会变成零值，无法溯源。唯一可靠方式是改用指针：
立即学习“go语言免费学习笔记（深入）”；
-
Timeout *int `json:"timeout"`→ 缺失时为nil，可用req.Timeout != nil判断 -
Name *string `json:"name"`→JSON {"name": null}和{}都让Name为nil，语义一致 - 注意解引用前必须判空：
if req.Timeout != nil { use(*req.Timeout) }，否则 panic
嵌套结构或动态字段用 json.RawMessage，别硬塞 map[string]interface{}
当配置中某个字段类型不确定（比如 "features" 可能是对象、数组、布尔值甚至 null），直接定义成 map[string]interface{} 会导致后续多层类型断言繁琐且易 panic。
json.RawMessage 是 []byte 别名，只暂存原始字节，不触发即时解析，更可控：
- 定义：
Features json.RawMessage `json:"features"` - 后续按需解析：
json.Unmarshal(req.Features, &featureMap)或json.Unmarshal(req.Features, &featureSlice) - 若要检查字段是否存在，可先将
RawMessage解析为map[string]json.RawMessage，再查 key - 注意：
RawMessage赋值前不校验 JSON 合法性，真正错误会在后续Unmarshal时暴露
验证字段合法性不能只靠结构体标签，得用 validator 库做运行时校验
结构体标签如 json:"port" 只管映射，不校验值是否合法。比如 "port": -1 或 "port": "abc"，前者会静默设为 0（int 零值），后者直接报错但信息模糊。
推荐用 go-playground/validator/v10 做字段级校验：
- 安装：
go get github.com/go-playground/validator/v10 - 加验证标签：
Port int `json:"port" validate:"required,gte=1,lte=65535"` - 解析后立即校验：
err := validate.Struct(config) - 错误处理：遍历
validator.ValidationErrors提取err.Field()和err.Tag()，返回具体字段 + 规则，比如"port must be between 1 and 65535"
复杂配置往往含必填、范围、格式等约束，仅靠解析无法兜底；validator 能把错误拦截在业务逻辑之前，且错误信息对运维和前端都友好。真正容易被忽略的是：字段缺失时零值语义和校验规则的冲突——比如 Port int 加了 required 标签，但缺失时仍是 0，校验器会认为它存在且非法，而非“缺失”。这时必须配合指针字段，才能让 required 真正生效。
