ShouldBind 不能直接绑定到接口类型，因为 Go 的反射和 json.Unmarshal 无法处理无字段、无内存布局的空接口；需用 map[string]interface{} 中转再二次解析，或实现自定义 UnmarshalJSON 方法、Binding 接口。
为什么 ShouldBind 不能直接绑定到接口类型
因为 Gin 的绑定器（如 ShouldBindJSON）底层依赖 Go 的反射和结构体标签解析，而接口类型本身没有可导出字段、没有固定内存布局，json.Unmarshal 或 form.Decode 都无法直接反序列化到一个空接口变量上。你写 var req interface{} 然后调 c.ShouldBind(&req)，会 panic 或静默失败——这不是 Gin 的 bug，是 Go 类型系统的限制。
用 map[string]interface{} 做中间层再分发
这是最常用也最可控的做法：先统一解析成通用结构，再根据业务逻辑（比如 type 字段）映射到具体结构体。适合请求体 schema 差异大、但顶层有明确区分标识的场景。
常见错误现象：json: cannot unmarshal object into Go value of type string —— 这往往是因为没提前声明接收类型，或误把 map 当 struct 用。
- 必须显式声明接收变量为
map[string]interface{}，不能用interface{} - 检查关键分发字段是否存在且类型正确，例如
req["type"]应该是string，不是float64（JSON 解析数字默认为 float64） - 构造具体结构体后，用
json.Unmarshal二次解析，别试图用 Gin 的ShouldBind直接绑到新 struct 指针上（它不认你刚 new 出来的空 struct）
示例片段：
立即学习“go语言免费学习笔记（深入）”；
var raw map[string]interface{}
if err := c.ShouldBindJSON(&raw); err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": "invalid JSON"})
return
}
reqType, ok := raw["type"].(string)
if !ok {
c.AbortWithStatusJSON(400, gin.H{"error": "missing or invalid 'type'"})
return
}
switch reqType {
case "create_user":
var req CreateUserReq
if err := json.Unmarshal([]byte(c.Request.Body.String()), &req); err != nil { /* ... */ }
case "update_profile":
var req UpdateProfileReq
if err := json.Unmarshal([]byte(c.Request.Body.String()), &req); err != nil { /* ... */ }
}定义统一接口 + 各实现的 UnmarshalJSON 方法
如果你希望保持面向接口的调用习惯（比如统一调 req.Validate()），可以为每个请求类型实现同一个接口，并重载 UnmarshalJSON。这样 Gin 仍用 ShouldBindJSON 绑定到接口变量，但实际反序列化逻辑由各类型自己控制。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
注意点：
- 接口变量必须是指针类型才能被
ShouldBindJSON修改，即var req Requester不行，得是var req *Requester（但此时你需要在UnmarshalJSON里处理 nil 指针） - 所有实现必须导出
UnmarshalJSON方法，且签名严格匹配：func (r *T) UnmarshalJSON(data []byte) error - Gin 不会自动识别实现类型，你仍需在方法内部根据数据内容判断并实例化具体 struct，再把字段复制过去
性能影响：每次都会触发两次 JSON 解析（一次进接口，一次进具体 struct），比直接解析到目标 struct 多一次拷贝和反射开销。
用 ShouldBindWith + 自定义 Binding 实现动态路由绑定
这是最灵活但也最容易出错的方式。你可以实现 binding.Binding 接口，在 Bind 方法里读取请求头或 body，动态选择目标 struct 并调用其 UnmarshalJSON 或 Decode。
典型使用场景：同一 URL 路径下，不同 Content-Type 或自定义 header（如 X-Req-Type: user）对应不同参数结构。
- 必须确保
Bind方法里完整读取c.Request.Body，否则后续绑定会读到空数据 - 不要在
Bind里修改c.Request.Body，而是用io.NopCloser包装新 reader 返回 - 错误处理要明确返回
binding.ErrInvalid或具体 error，否则 Gin 会吞掉并返回 400 却不带提示
容易被忽略的是：Gin 默认的 ShouldBind 系列方法不会自动识别你注册的自定义 binding，必须显式调用 c.ShouldBindWith(&req, yourBinding)。
