Gin中Query参数获取需确保URL含标准query string（如?name=alice&age=25），c.Query()返回空字符串时参数不存在，c.DefaultQuery()可设默认值，c.GetQuery()额外返回存在标识，结构体绑定推荐c.ShouldBindQuery()。
Query参数没收到？先检查请求URL格式是否正确
Gin不会自动解析URL中缺失?key=value结构的字符串，比如/api/user后面直接跟id=123（没问号）或空格分隔，Gin会忽略这部分。必须确保前端发的是标准query string：/api/user?name=alice&age=25。
常见错误现象：c.Query("name")始终返回空字符串，但c.Request.URL.RawQuery里能看到原始串——说明URL本身不合规，不是Gin的问题。
- 浏览器地址栏手动测试时，务必用
?开头，多个参数用&连接 - 前端fetch/Axios要传
URLSearchParams对象或拼好字符串，别直接往url后+对象字面量 - Postman里选“Params” tab填键值，别填在“Body”或“URL”输入框末尾
c.Query()和c.DefaultQuery()的区别在哪
c.Query("page")只返回URL中实际存在的值，参数不存在时返回空字符串""；而c.DefaultQuery("page", "1")在参数缺失时返回默认值"1"，适合分页、状态开关等有合理默认值的场景。
注意：两者都返回string，不做类型转换。想转int得自己调strconv.Atoi()，且必须处理错误。
立即学习“go语言免费学习笔记（深入）”；
- 不要写
page, _ := strconv.Atoi(c.Query("page"))——万一参数是page=abc，会得到0，逻辑出错 - 推荐写法：
if pageStr := c.Query("page"); pageStr != "" { if page, err := strconv.Atoi(pageStr); err == nil { /* use page */ } } -
c.GetQuery()和c.Query()行为一致，只是前者多返回一个bool表示参数是否存在，适合需要区分“空值”和“未传”的场景
批量获取Query参数：用c.Request.URL.Query()还是c.ShouldBindQuery()
如果参数多（比如搜索接口带q、sort、offset、limit），逐个调c.Query()啰嗦且难维护。两种更高效的方式：
c.ShouldBindQuery(&struct{...})会自动把URL query映射到结构体字段，支持form标签、指针字段、嵌套结构（需额外配置），还做基础校验（如binding:"required"）。
c.Request.URL.Query()返回url.Values（本质是map[string][]string），适合需要原生多值（如?tag=go&tag=web）、或做动态键名处理（比如白名单过滤）的场景。
-
ShouldBindQuery对空字符串、零值字段不做特殊处理，binding:"required"只在校验时生效，不阻止绑定 - 结构体字段名必须大写（可导出），否则绑定失败；
form:"xxx"标签可覆盖字段名映射 -
url.Values里同一个key对应[]string，Get("key")只取第一个，["key"]取全部——这点常被忽略，导致多值漏处理
中文Query参数乱码？别忘了前端和Gin都要UTF-8
浏览器默认用UTF-8编码query参数，但若前端JS手动拼接URL且没编码，或后端没正确解码，就会出现%E4%BD%A0%E5%A5%BD变成乱码。Gin内部用url.QueryUnescape自动解码，前提是原始字节流是合法UTF-8。
- 前端必须用
encodeURIComponent("你好")，而不是encodeURI或不编码 - 避免在URL里传JSON字符串等复杂结构——容易因嵌套编码/解码错位导致乱码或解析失败
- Gin不主动修改
Content-Type，但若用c.Header("Content-Type", "text/plain; charset=utf-8")响应，能减少客户端解析歧义
Query参数这事看着简单，真正卡住人的往往不是Gin用法，而是URL编码链路上某一处没对齐：前端拼串没encode、Nginx代理重写了query、甚至CDN缓存了未解码的原始请求。遇到异常，先打印c.Request.URL.String()和c.Request.URL.RawQuery比对最靠谱。
