ShouldBind 不适合网关层参数校验，因其为单 handler 设计，依赖结构体标签、会直接 panic 或写响应、无法在中间件中提取原始参数预处理，且不支持 query 与 form 混合校验；网关需手动解析 URL.Query、PostForm 和 Body 并统一校验。
为什么 Gin 的 ShouldBind 不适合网关层参数校验
网关层需要统一拦截、转换、校验所有入参，而 ShouldBind 是为单个 handler 设计的：它依赖结构体标签（如 json、form）、会直接 panic 或写 response、无法在中间件中优雅提取原始参数做预处理。一旦校验失败，你没法统一记录 traceID、返回标准化错误码，甚至可能漏掉 query 和 form 混合场景。
真正可行的做法是绕过绑定，手动解析 c.Request.URL.Query()、c.Request.PostForm 和 c.Request.Body，再用通用规则校验。中间件里别碰 ShouldBind，它不是为网关准备的。
如何在 Gin 中间件里安全读取并合并全部参数
HTTP 请求参数分散在 URL query、POST form、JSON body 三处，网关必须一并收集。但 c.Request.Body 只能读一次，且 c.Request.ParseForm() 会自动消费 body（对 JSON 无效），容易出错。
- 先调用
c.Request.ParseForm()—— 它会把 query 和 form 合并进c.Request.Form，但不会动 body - 再判断
Content-Type：如果是application/json，用io.ReadAll(c.Request.Body)读取原始字节，然后用json.Unmarshal解析成map[string]interface{} - 最后把
c.Request.Form和 JSON map 合并成一个顶层map[string]interface{}，注意 key 冲突时 JSON 优先（或按业务约定） - 务必在读完 body 后，用
c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))重置 body，否则下游 handler 会收不到数据
校验逻辑怎么做到可插拔又不侵入业务 handler
校验规则不能硬编码在中间件里，否则每次加字段都要改网关。推荐用“校验器注册表”模式：定义一个接口 Validator，每个业务路由注册自己的校验器实例，中间件通过 c.Get("validator") 获取并执行。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
示例注册方式：
r.POST("/order/create", func(c *gin.Context) {
c.Set("validator", &OrderCreateValidator{})
gatewayMiddleware(c)
})
中间件里只做通用动作：提取参数 → 找 validator → 调 Validate(params) → 错误则 c.AbortWithStatusJSON(400, ...)。validator 实现里可复用 go-playground/validator/v10，但输入必须是 map，不是结构体。
常见坑：空字符串、零值、数组嵌套怎么处理
网关层看到的原始参数全是字符串，"0"、""、"null"、"[]" 都得识别。别指望 JSON 解析器自动转类型——json.Unmarshal 把 "0" 当 string，"false" 当 bool，但 "0.0" 可能变成 float64，类型不一致会导致校验逻辑混乱。
- 统一在参数合并后做类型归一化：比如把所有数字字符串尝试转
float64，失败则留原 string；布尔值只认"true"/"false"（忽略大小写），其他算非法 - 数组字段如
ids[]=1&ids[]=2，c.Request.Form["ids"]是[]string{"1","2"}，但 JSON 里可能是"ids": [1,2]，合并时需统一成 slice - 空字符串
""和缺失字段语义不同，校验器要区分required和nonempty规则
最麻烦的是嵌套对象，比如 user.name 这种点号路径，原始参数里根本不存在——必须靠前端传 flat 结构（user_name）或网关主动解析 JSON 层级，后者性能敏感，建议限制嵌套深度 ≤3。
