c.ShouldBind 默认只解析请求体（body），不处理URL查询参数；需用c.ShouldBindQuery显式绑定query，且结构体字段必须带form标签。
c.ShouldBind 不会读 URL 查询参数，别指望它“自动全包”。它默认只解析请求体（body），比如 JSON 或 application/x-www-form-urlencoded 数据；query 参数必须显式用 c.ShouldBindQuery，且结构体字段得带 form 标签。
为什么 c.ShouldBind 拿不到 ?page=2&size=10
因为 c.ShouldBind 的行为由 Content-Type 驱动：它看到 application/json 就走 json.Unmarshal，看到 application/x-www-form-urlencoded 就走表单解析，但完全忽略 r.URL.Query()。URL 查询参数是扁平字符串，不是 body 的一部分，框架不会主动合并。
- 常见错误现象：结构体字段始终为零值（如
Page是 0、Name是空字符串） - 调试时检查
c.Request.URL.Query()能确认参数确实存在，但没被绑定 - 别依赖
Content-Type: application/json同时传 query —— Gin 不会从 URL 提取字段填进 JSON 解析后的 struct - 如果接口设计上确实要混合使用（比如分页 + 创建数据），就得拆开调用：
c.ShouldBindQuery(&q)和c.ShouldBindJSON(&b)，再手动组合逻辑
form、json、uri 标签不能混用在同一字段
同一个字段同时加 json:"id" 和 form:"id" 看似方便，实则破坏来源可控性：验证规则、类型转换路径、错误定位都会变模糊。Gin 绑定器按来源选择对应标签，但冲突时行为不明确，尤其在 fallback 场景下容易静默失败。
- GET 请求用
c.ShouldBindQuery→ 只认form标签 - POST JSON 用
c.ShouldBindJSON→ 只认json标签 - 路径参数（如
/users/:id）用c.ShouldBindUri→ 只认uri标签 - 切片字段如
[]string：query 传?tags=a&tags=b，结构体必须写form:"tags"；JSON 传{"tags":["a","b"]}，则必须写json:"tags"；写错就为空切片
类型转换不是隐式发生，而是靠标签或底层函数显式触发
Go 没有类型自动推导绑定，所有转换都需明确路径。比如表单里传 age=25（字符串），要转成 int 字段，Gin 默认调用 strconv.Atoi；但如果传的是空字符串或非数字，就会直接报错，不会设默认值或跳过。
立即学习“go语言免费学习笔记（深入）”；
- 想容错处理字符串数字（如 HTML 表单常见情况），得加
form:"age,string"标签，启用内置字符串转数字逻辑 - 时间字段如
time.Time必须配合time_format子标签，例如form:"created_at" time_format:"2006-01-02" - 自定义类型（如枚举）需实现
encoding.TextUnmarshaler接口，否则绑定失败 - 别在结构体字段上直接写
int却传字符串，也不要用interface{}期望框架自动猜——它不会
Header 和路径参数绑定没有“自动”一说
Gin 原生不支持 Header 绑定，c.ShouldBind 系列方法根本不看 c.Request.Header；路径参数（:id）也需单独用 c.ShouldBindUri，且结构体字段必须带 uri 标签。
- Header 参数（如
Authorization、X-Request-ID）只能手动取：c.Request.Header.Get("Authorization") - 路径参数绑定失败的典型原因是：没调
c.ShouldBindUri，或结构体字段漏了uri:"id"，或路由没注册/{id}这种命名段 - GoFrame 等框架虽提供
BindRequest尝试智能合并，但它内部仍是分源解析，Header 仍需显式声明标签（如header:"X-Token"），并非真“自动”
参数绑定的本质是“明确来源 + 显式映射”，不是魔法。最容易被忽略的点是：你以为框架在帮你猜，其实它只按你写的标签和调用的方法做事；一旦来源和标签不匹配，就静默失败或填零值，连日志都不报。
