ShouldBind 默认不丢弃未知字段，遇未定义字段直接忽略且不报错；需用 json.Decoder.DisallowUnknownFields() 实现严格绑定，或结合 validator 校验已绑定字段，但 validator 无法检测未知字段。
ShouldBind 默认不丢弃未知字段，必须显式配置
Gin 的 c.ShouldBind 和 c.ShouldBindJSON 默认行为是“宽松解析”：遇到 JSON 中存在结构体未定义的字段时，直接忽略，不报错也不过滤。这看似省事，实则埋下隐患——前端多传一个调试字段（如 debug: true），后端完全感知不到，可能绕过校验或干扰逻辑。
这不是 bug，是设计选择：Gin 依赖底层 json.Unmarshal，而后者默认忽略未知字段。要实现“自动过滤冗余字段”，得换绑定方式或加中间层。
- 用
c.ShouldBindWith(&req, binding.JSON)并传入自定义binding.Binding实现，但 Gin 官方不提供开箱即用的“严格模式”绑定器 - 更实际的做法：改用
json.Decoder配合DisallowUnknownFields()，再手动触发 validator 校验（Validate.Struct()） - 若坚持用 ShouldBind，可在结构体上加
json:",omitempty"+ 全字段显式声明，但这只是“防御性建模”，不是真正过滤
用 json.Decoder.DisallowUnknownFields 实现严格 JSON 绑定
这是目前最可控、无额外依赖的方案。它在反序列化阶段就拦截未知字段，比靠 validator 后置校验更早、更彻底。
示例关键代码：
立即学习“go语言免费学习笔记（深入）”；
decoder := json.NewDecoder(c.Request.Body)
decoder.DisallowUnknownFields()
var req CreateUserReq
if err := decoder.Decode(&req); err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": "unknown field in JSON"})
return
}
// 再走 validator 校验业务规则
if err := validator.New().Struct(req); err != nil {
// 处理 required/min/email 等
}
- 注意：必须在
decoder.Decode前调用DisallowUnknownFields()，否则无效 - 该方法对空 body 或非 JSON Content-Type 会 panic，需前置检查
c.GetHeader("Content-Type") - 它不处理 query、form、uri 参数，仅作用于 JSON body
query 和 form 场景下无法自动过滤，只能靠结构体字段收口
URL query（?a=1&b=2&c=3）和表单（application/x-www-form-urlencoded）没有标准的“未知字段拒绝”机制。Gin 的 c.ShouldBindQuery 和 c.ShouldBindForm 本质是把键值对映射到结构体字段，没声明的字段就自然被丢弃——这看起来像“过滤”，其实是“不绑定”，并非主动校验。
- 风险在于：如果结构体字段名写错（比如
Usrname写成Username），对应 query 字段就静默丢失，难定位 - 安全做法是：所有接收 query/form 的结构体，字段必须带明确 tag，如
Page int `form:"page" json:"page" binding:"required"`，避免依赖字段名 fallback - 别指望
binding:"-"能过滤 query —— 它只禁用绑定，不阻止参数被读取；想审计/记录所有收到的 query，得手动解析c.Request.URL.Query()
validator 不能替代字段过滤，它只校验已绑定的值
很多人误以为加了 binding:"required" 就能挡住未知字段，其实 validator 完全不关心“字段是否存在”，只检查“已绑定字段的值是否合规”。一个没在结构体里声明的 token 字段，无论是否传了，validator 都看不见。
- validator 错误信息里永远只有已知字段名，不会告诉你 “你多传了 xxx 字段”
- 跨字段校验（如
gtfield=Password）的前提是两个字段都在结构体中且已绑定 - 如果真需要运行时发现并拒绝未知字段，唯一可靠路径是：先用
json.RawMessage接收原始 body，解析为map[string]any，比对 keys 与预期字段列表，再决定是否继续
真正难的不是“怎么过滤”，而是“要不要过滤”——很多内部接口靠宽松绑定兼容历史客户端，而对外 API 才需要严格字段控制。一旦选了严格模式，就得同步约束所有上游调用方，否则上线即报错。
