shouldbind不校验空值，需显式加binding:"required"；nil指针需用exists；自定义验证器须在gin.default()后注册且名称严格匹配；shouldbind比mustbindwith更推荐；中间件中不可直接调用shouldbindjson，应手动预检json格式。
ShouldBind 为什么没报错但参数是空的？
因为 ShouldBind 只负责“解析”，不负责“校验”——它只在 JSON 格式错误、字段类型不匹配时返回 error；而字段缺失、为空、为零值，默认完全不触发任何校验逻辑。
- 必须显式加
binding:"required"才会拦截缺失字段 -
Age *int `binding:"required"`永远不会报错，因为 validator 跳过 nil 指针；改用Age int `binding:"required,exists"`或Age *int `binding:"exists"` -
exists是关键：它检查请求体里“有没有这个 key”，而不是“值是不是空” - 别指望
json:",omitempty"影响绑定行为——它只控制序列化，和校验无关
怎么注册自定义验证器才真正生效？
注册失败是 Gin 参数校验里最隐蔽的坑：代码写了、tag 也对了，但函数压根不进，错误提示还是 Field validation for 'Phone' failed on the 'chinese_mobile' tag。
- 必须在
gin.Default()或gin.New()之后立即注册，不能放init()里（此时binding.Validator.Engine()可能为nil） - 注册名（如
"chinese_mobile"）必须和 struct tag 里写的完全一致，大小写敏感 - 验证函数签名固定为
func(fl validator.FieldLevel) bool，多一个参数或返回error都会静默失效 - 重复注册同一名称会 panic，加个
if !v.HasRegisteredNamespace("chinese_mobile")防御更稳
ShouldBindJSON 和 MustBindWith 到底选哪个？
MustBindWith 在 Gin v1.9+ 已被标记为 deprecated，官方明确倾向用 ShouldBind + 显式错误处理。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
-
ShouldBind灵活但易漏return：常见错误是写了if err != nil { c.JSON(400, ...) }却忘了return，后续代码继续用零值执行 -
MustBindWith会自动AbortWithError，但掩盖了流程控制权，不利于统一错误格式（比如加code字段） - 对外 API 建议用
ShouldBind+ 统一错误响应结构；内部管理接口可酌情简化 - 性能无差异，二者底层都走 validator.Struct，区别只在错误出口路径
中间件里能不能提前做参数校验？
不能直接调 c.ShouldBindJSON() 或 c.BindJSON() —— 一旦遇到非法 JSON，Gin 会直接 panic，而中间件没默认错误兜底机制。
- 正确做法是手动读 body：
data, _ := io.ReadAll(c.Request.Body)，然后json.Unmarshal(data, &raw)预检格式 - 预检失败就
c.AbortWithStatusJSON(400, ...)，成功则重置 body：c.Request.Body = io.NopCloser(bytes.NewReader(data)) - 别用
c.GetRawData()（已 deprecated），也别依赖gin.Recovery()来“兜住”校验 panic - binding 标签在中间件里完全无效——它只在
ShouldBind*系列函数中被解析
最常被忽略的一点：校验不是“可开关功能”，而是数据进入业务逻辑前的强制门禁。哪怕只是 id 路径参数，也该用 c.ShouldBindUri + binding:"required,numeric" 过一遍，否则后面查 DB 报 invalid syntax 或空指针，问题根源早就在第一层丢了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
