用 validator 库校验结构体字段最直接：为字段添加 validate tag（如 required,min=2），绑定 JSON 后调用 validate.Struct()，错误类型为 validator.ValidationErrors，需区分 BindJSON 解析错误与校验错误，避免误用 omitempty 跳过 required 检查。
用 validator 库做结构体字段校验最直接
Go 初级项目里，参数校验最常见场景是 HTTP 请求体（json）绑定到结构体后立刻检查。不手动写一堆 if err != nil，直接用社区主流的 github.com/go-playground/validator/v10 是最快落地的方式。
它支持 tag 驱动、链式规则、国际化错误提示，且无反射性能陷阱（v10 默认使用代码生成可选）。初级项目够用，后期也容易升级。
-
struct字段加validatetag，比如type User struct { Name string `validate:"required,min=2,max=20"` } - 绑定请求后调用
err := validate.Struct(user)，非 nil 即校验失败 - 错误类型是
validator.ValidationErrors，可遍历获取具体字段和规则名 - 避免在 tag 里写逻辑复杂表达式（如嵌套函数），初级项目只用内置规则即可
HTTP handler 中别漏掉 BindJSON 和 Validate 的顺序
很多人用 gin 或 echo 时，以为 c.BindJSON(&v) 自带校验，其实它只负责反序列化——空字符串、零值、类型转换失败会报错，但 required、email 这类业务规则完全不检查。
必须显式补上校验步骤，否则参数看似“进了结构体”，实际是脏数据。
- 正确顺序：
if err := c.BindJSON(&req); err != nil { /* 处理解析错误 */ }→if err := validate.Struct(req); err != nil { /* 处理校验错误 */ } - 不要合并成一个 if：解析失败和校验失败的错误类型、处理方式、HTTP 状态码通常不同（前者 400，后者也常是 400，但错误信息语义不同）
- 如果用
gin，可封装中间件或自定义ShouldBind方法，但初级项目建议先手写两步，更可控
validator 的 omitempty 容易误用导致跳过必填检查
当字段是空值（""、0、nil）且 tag 带 omitempty 时，validator 默认会跳过该字段所有规则——包括 required。这跟 JSON 序列化的 omitempty 语义无关，是 validator 自己的开关机制。
初级项目最容易在这里踩坑：用户传了 {"name": ""}，结构体字段是 string 类型 + validate:"required,omitemtpy"，结果校验通过。
- 去掉
omitempty：除非你明确需要“字段不存在时跳过校验”，否则别加 - 想实现“字段存在才校验”，用
required_if或required_with等条件规则 - 对字符串类型，
required本身已覆盖空字符串场景；加min=1是冗余但更显式
简单查询参数校验用 url.Values 手动取 + strconv 转换更轻量
对于 GET 请求的 query 参数（如 /users?page=1&size=10），没必要强塞进结构体再走 validator。初级项目直接用标准库更清晰、无依赖、易调试。
重点不是“统一用一种方式”，而是匹配场景：body 用结构体 + validator，query 用原生解析更自然。
pageStr := c.Query("page")
if pageStr == "" {
// 返回 400，提示 page 缺失
}
page, err := strconv.Atoi(pageStr)
if err != nil || page < 1 {
// 返回 400，提示 page 格式或范围错误
}-
c.Query()返回空字符串表示参数未提供，c.DefaultQuery()才有默认值语义 - 数字类参数务必检查转换错误 + 业务范围（如
page > 0、size ） - 布尔参数别依赖
strconv.ParseBool的宽松模式（"1"、"on"都算 true），初级项目只认"true"/"false"字符串
真正麻烦的从来不是“怎么加校验”，而是校验失败后怎么把错误映射成前端能理解的字段级提示。tag 里的规则名（如 required）要跟返回的错误字段对齐，否则前端只能显示“参数错误”这种废信息。
