validator 的 min/max 标签对数值类型有效，但零值字段默认被跳过，需加 required 才校验；指针 nil 也被跳过，浮点数需防精度误差，建议金额用整数或 decimal 类型。
用 validator 校验数值范围：字段标签怎么写才生效
Go 的 validator 库（比如 go-playground/validator/v10）本身不直接支持 min=1,max=100 这种写法对所有数值类型通用——它依赖底层类型实现 Interface() 或具体方法，而 int/float64 等基础类型没实现校验逻辑，必须靠反射取值后手动比对。
所以你写 type User struct { Age int `validate:"min=0,max=150"` } 是能跑的，但前提是：Age 字段不能是零值（比如传了 0），否则 min=0 会误判为“合法”，因为 validator 默认跳过零值字段（除非加 required）。
-
min/max标签只对int、int64、float64、uint等数值类型有效，对*int指针也有效（会自动解引用） - 如果字段是
*int且为nil，默认不校验；加required才会触发非空检查，再走min/max - 浮点数用
min=0.1,max=99.9没问题，但注意精度丢失可能导致边界判断意外失败（比如0.1+0.2 != 0.3）
min 和 max 在指针与零值场景下的行为差异
这是最容易踩坑的地方：字段为 int 类型时，值为 0 会被当成“未设置”跳过 min/max；而 *int 为 nil 也会被跳过。但两者语义完全不同——0 是有效业务值（比如年龄 0 表示新生儿），nil 才是未提供。
- 要允许
0并参与范围校验，必须加omitempty的反面：显式写required，例如Age int `validate:"required,min=0,max=150"` - 如果字段是
*int，且想区分“未传”和“传了 0”，就别用required，改用自定义验证函数，或用gt=-1（表示 > -1，即 ≥ 0）来隐式要求非负 -
omitempty标签和validator无关，它只影响 JSON 序列化；validator看的是字段实际值，不是 tag
浮点数校验要注意精度和比较方式
validator 对 float64 的 min/max 是直接用 和 <code>>= 比较的，不走 math.Abs(a-b) 。这意味着如果你从 JSON 解析来一个 <code>"3.14"，它变成 float64 后可能有微小误差，但通常不影响边界判断——真正危险的是人为构造的浮点计算结果。
- 避免用表达式结果直接校验：比如
Price float64 `validate:"min=0.01"`是安全的；但Price = math.Round(x*100)/100后再校验，可能因舍入误差导致0.010000000000000002 > 0.01被放过 - 如果业务要求严格精度（如金额），建议用整数存储分，或用
decimal类型，再配自定义校验函数 - 测试时别只测整数边界，加一个
0.009999999999999999和0.010000000000000002看是否按预期拒绝/通过
自定义数值范围校验函数更可控
当内置 min/max 不够用（比如要支持动态范围、依赖其他字段、或需要容错比较），就得注册自定义函数。它比标签灵活，也能绕过零值跳过逻辑。
- 注册函数示例：
validate.RegisterValidation("range", rangeValFunc)，然后字段写`validate:"range=1,100"` - 函数里可以做类型断言、处理指针、调用
math.Round或big.Rat，甚至查数据库限制 - 注意：自定义函数接收的是
interface{}，需自己判断是否为数值类型，否则 panic - 性能上，自定义函数比内置标签略慢（多一次函数调用+类型判断），但对单次请求可忽略；高频校验场景建议先 benchmark
边界值、零值、指针、浮点精度——这几个点混在一起时，min/max 就容易漏掉真实业务约束。别依赖文档里“支持 float64”那句话，亲手试下 0、nil、0.1+0.2 这三类输入。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
