Gin 本身不提供“入参清洗器”，但可通过中间件+ShouldBind+自定义 binding 实现统一清洗；清洗须在绑定后、业务前执行，推荐结构体 Clean() 方法+中间件调用，或集成 StructValidator。
直接上结论：Gin 本身不提供“入参清洗器”这个抽象概念，但你可以用中间件 + ShouldBind 系列方法 + 自定义 binding 规则，低成本实现统一、可复用、可插拔的入参清洗逻辑。关键不在“造轮子”，而在“控制清洗时机和作用域”。
为什么不能只靠 ShouldBindJSON 做清洗
它只做校验和结构体映射，不处理字段标准化（比如空字符串转 nil、HTML 标签剥离、手机号去空格/加号、时间字符串归一化）。如果你在每个 handler 里手动调 strings.TrimSpace 或正则替换，会重复、难维护、易漏。
常见错误现象：POST /user 提交 {"name":" Alice ","phone":"+86 138-0013-8000"}，后端直接存了带空格的 name，或没标准化 phone 导致查不到用户。
实操建议：
- 清洗必须发生在绑定之后、业务逻辑之前，否则清洗结果无法进入 struct 字段
- 不要在 binding tag 里写清洗逻辑（如
binding:"required,trim"是无效的） - 清洗函数应接收指针，原地修改 struct 字段值，避免拷贝开销
用中间件 + c.Set() 实现轻量清洗链
适合字段清洗规则简单、跨多个接口复用的场景（如所有 API 都要 trim string、转小写邮箱、标准化时间格式）。
示例：一个通用字符串清洗中间件
func TrimStringMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
// 先让后续绑定发生
c.Next()
// 绑定完成后，从上下文取刚解析出的结构体（需提前约定 key）
if raw, ok := c.Get("bind_payload"); ok {
if payload, ok := raw.(interface{ SetFields() }); ok {
payload.SetFields() // 调用清洗方法
}
}
}
}
但更推荐的做法是：把清洗逻辑封装进 struct 的方法里，由中间件统一触发：
- 定义结构体时实现
Clean()方法：func (u *UserReq) Clean() { u.Name = strings.TrimSpace(u.Name); u.Email = strings.ToLower(strings.TrimSpace(u.Email)) } - 中间件中，在
c.ShouldBindJSON(&u)成功后立即调用u.Clean() - 用
c.Set("cleaned", &u)把清洗后的实例透传给 handler，避免重复绑定
用自定义 binding.StructValidator 深度集成清洗
这是 Gin 官方支持的扩展点，清洗与校验耦合最紧、侵入性最小的方式。适用于需要清洗后立刻校验（比如清洗掉空格后判断是否 still empty）的场景。
步骤：
- 实现
binding.StructValidator接口，重写ValidateStruct方法 - 在
ValidateStruct中对目标 struct 字段做清洗，再调用默认 validator - 全局注册：
binding.Validator = &CustomValidator{}
注意：此方式清洗逻辑对所有 ShouldBind* 生效，无法按路由开关；且 Gin v1.9+ 对 validator 接口有变更，务必核对 github.com/go-playground/validator/v10 版本兼容性。
清洗时机选错会导致数据丢失或 panic
最容易踩的坑是清洗放在 c.Next() 之前 —— 此时 c.MustGet("bind_payload") 还没被设置，取不到数据；或者清洗逻辑里访问了未初始化的嵌套 struct 字段，引发 panic。
正确顺序只能是：
- 注册中间件（顺序决定执行时机）
- 调用
c.ShouldBindJSON(&v)（此时完成解码） - 立即清洗
v（此时v是有效地址） - 再调
c.Next()进入业务 handler
复杂点在于：如果请求体是 multipart/form-data 或 query 参数，ShouldBind 行为不同，清洗字段类型也要区分处理 —— 比如 form 表单里的文件字段不能 trim，而 text 字段必须 trim。这点常被忽略。
