启用 DisallowUnknownFields() 是最直接的防御手段，需通过 json.Decoder 实例调用并配合白名单校验、json:"-" 标签规范及自定义 UnmarshalJSON 方法实现多层防护。
启用 DisallowUnknownFields() 是最直接的防御手段
Go 默认容忍未知字段，攻击者可借此注入恶意键名触发逻辑异常或覆盖内部状态。启用严格模式后，只要 JSON 中出现结构体未定义的字段，json.Unmarshal 就会立即报错，而不是静默丢弃。
实际操作必须用 json.Decoder 实例，不能直接调用 json.Unmarshal：
- 先创建
decoder := json.NewDecoder(r)（r是io.Reader，比如bytes.NewReader(data)或 HTTP 响应体） - 紧接着调用
decoder.DisallowUnknownFields() - 再执行
decoder.Decode(&v)
注意：该方法只对结构体生效；若目标是 map[string]interface{} 或 interface{}，它无效——因为这类类型本就“接受一切”。
用 json.RawMessage 延迟解析 + 白名单校验更可控
当需要保留未知字段用于审计、日志或后续动态处理时，DisallowUnknownFields() 会直接拒绝请求，不够灵活。此时应改用“先全量接收、再按需提取”策略。
立即学习“go语言免费学习笔记（深入）”；
核心是把原始 JSON 先解到 map[string]json.RawMessage，再手动比对白名单：
- 定义允许字段列表：
allowed := []string{"name", "email", "age"} - 遍历
map的所有 key，检查是否在白名单中 - 对每个合法 key，用
json.Unmarshal(rawMsg, &target)单独解析，并做类型/范围校验（如age是否在 0–120 之间） - 对非法 key，可记录告警、丢弃，或存入
overflow字段供追溯
这种做法绕过了结构体绑定，也规避了反射风险，适合对接文档不全但又需强校验的第三方 API。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
json:"-" 标签写错会导致忽略失效
想让某个字段彻底不参与反序列化，必须写成 json:"-"（冒号后紧接短横，**中间不能有空格**）。常见错误包括：json: "-"、json:" - "、json:"- "——这些都会导致标签解析失败，字段照常参与解码，可能意外被赋值。
尤其要注意：
- 该标签对导出字段（首字母大写）才有效；非导出字段（小写开头）本身就不会被 JSON 包访问，加不加标签都一样
-
json:"-"和json:",omitempty"行为不同：omitempty只影响序列化（输出），反序列化时仍会尝试填充；-则双向屏蔽 - 建议用
go vet或staticcheck扫描 struct tag，自动捕获空格类低级错误
自定义 UnmarshalJSON 方法能实现细粒度控制
对关键结构体（如用户凭证、配置项），推荐显式实现 UnmarshalJSON 方法。它让你完全掌控解析流程，比如提前校验字段数量、拦截危险键名、限制嵌套深度等。
典型写法：
- 在方法内新建
json.Decoder，并立即调用DisallowUnknownFields() - 用
decoder.Token()或decoder.More()检查是否为对象起始、是否有多余字段 - 对每个字段名，手动
decoder.Decode()到对应临时变量，再做业务校验（如正则匹配邮箱、枚举值比对） - 避免在方法内调用
json.Unmarshal递归解析，防止栈溢出或循环引用
这种方式成本略高，但安全边界清晰，适合金融、权限等高敏感场景。别把它当成通用方案——只在真正需要时才上。
真正麻烦的是混合场景：既要兼容旧版 API 的额外字段，又要防新字段注入。这时候单靠一个开关或一个标签解决不了，得组合用 RawMessage + 白名单 + 自定义方法，而且每层校验点都要留日志。否则问题暴露时，你根本不知道是哪一层漏了。
