Gin 默认不自动 trim 字符串参数，因其遵循 HTTP 规范原样解析，需通过中间件统一处理 Query/Form 参数或自定义 JSON binding 实现安全 trim。
直接说结论：Gin 本身不提供自动 trim 字符串参数的机制，必须手动干预；但可以通过中间件 + 自定义绑定逻辑统一处理，避免在每个 handler 里重复写 c.Query("xxx").TrimSpace() 或 strings.TrimSpace()。
为什么 Gin 默认不 trim 参数？
Gin 遵循 HTTP 规范原样解析 URL 编码后的字符串，+ 被解码为空格、%20 保持为字面空格——这些都属于标准行为。它不假设“所有字符串都要 trim”，因为业务场景可能需要保留首尾空格（比如密码字段、富文本前缀等）。
常见错误现象包括：
- 前端传
?name= admin，后端拿到" admin "，数据库查不到 - JSON 请求体中
{"username": " test "}，校验时== "test"失败 - 表单提交含
+的值（如数学表达式），被悄悄转成空格
GET/POST 表单参数：用中间件统一 Trim Query 和 FormValue
对 application/x-www-form-urlencoded 和 URL 查询参数，最轻量的方式是拦截 *gin.Context 的原始参数读取逻辑。
实操建议：
- 不要改
c.DefaultQuery()或c.PostForm()的返回值（它们是只读封装） - 写一个中间件，在
c.Request.URL.RawQuery和c.Request.PostForm解析前做预处理 - 更稳妥的做法：封装一层
SafeQuery/SafePostForm工具函数，内部调用strings.TrimSpace() - 示例：
func SafeQuery(c *gin.Context, key string, defaultValue string) string { s := c.DefaultQuery(key, defaultValue) return strings.TrimSpace(s) }
JSON 请求体：用自定义 binding 替换 c.ShouldBindJSON()
JSON 场景下，trim 必须发生在结构体字段赋值阶段，否则 json.Unmarshal 已完成解析，再 trim 就晚了。
实操建议：
- 给需要 trim 的字段加自定义 tag，比如
json:"name" trim:"true" - 实现一个兼容原生
ShouldBindJSON的 wrapper，用反射遍历 struct 字段，对带trimtag 的 string 类型字段自动调用strings.TrimSpace - 避免重写整个 binding 逻辑，可复用
jsoniter或encoding/json的 Unmarshal，仅做 post-process - 注意：如果字段是指针（
*string），需判空再 trim，否则 panic
容易被忽略的边界点
真正踩坑的地方往往不是“怎么 trim”，而是“什么时候不该 trim”：
-
Content-Type: text/plain或 raw body 场景，不能无脑 trim 整个 body - Base64 编码字符串、JWT token、加密密钥等，首尾空格可能是有效数据
- URL 中的
+在 query string 里本就表示空格，若业务真需要传递字面+，应前端 encodeURIComponent，后端不做额外 decode - 使用
c.Param("id")获取路径参数时，Gin 不会做任何 decode（除非你开了gin.DisableHTTP2等非常规配置），但路径中若含%20，仍会被自动转为空格——这个转换发生在 net/http 层，无法绕过
