Fiber中结构体绑定与验证分离，c.BodyParser()不识别validate标签，需手动设置app.Validator；路径/查询参数无法自动绑定，须手动提取并校验。
结构体绑定和验证在 Fiber 中是两件独立的事，框架不自动串联；c.BodyParser() 只负责解码，validate 标签默认完全不生效，必须手动集成校验器才能触发。
BodyParser 不读 validate 标签，只认 binding
Fiber 的 c.BodyParser(&v) 底层用的是 binding.DefaultValidator，它只识别 binding:"required" 这类 tag，对 validate:"required,email" 视而不见。哪怕你结构体里同时写了两种 tag，validate 也始终是摆设。
- 想让
validate生效，必须提前给app.Validator赋一个实现了binding.StructValidator接口的实例 - 这个赋值必须在注册任何路由前完成，否则中间件已初始化，改了也无效
-
c.ShouldBind()和c.BodyParser()行为一致，默认都不走validate；别指望换函数名就能绕过限制 - 常见错误：结构体字段写
json:"email" validate:"required,email"，但没设app.Validator，结果空邮箱照样通过
怎么正确挂上 go-playground/validator
推荐复用官方 validator 实例，在 ValidateStruct 方法里做包装，既保留基础规则，又能加业务逻辑。
- 先
go get github.com/go-playground/validator/v10 - 定义类型：
type customValidator struct{ validator *validator.Validate } -
ValidateStruct里调v.validator.Struct(val)，再把返回的error转成validator.ValidationErrors（不是直接 returnerror） - 字段名要用
fe.Field()（对应 JSON key），不是fe.StructField()（Go 字段名），否则前端传{"user_email": "x@y.z"}时校验提示会错乱 - 嵌套结构体中
eqfield=Password失效？因为它是同级查找——要么拉平字段，要么注册自定义函数，用反射取父级字段
required 拦不住空格，min=1 也得小心写法
validate:"required" 对 " "、" \t\n" 完全放行，这是高频翻车点。前端提交带空格的用户名或邮箱，后端校验通过，业务层一调 strings.TrimSpace() 就发现是空字符串。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 临时解法：
validate:"required,min=1"（注意min=1前不能有空格，否则解析失败） - 根治方案：注册
notblank自定义规则，内部先strings.TrimSpace()再判空 - 数字字段别信
c.Params("id")是整数字符串就直接int()，必须用strconv.Atoi()或strconv.ParseInt()并检查err - 密码确认字段比对，别用
eqfield硬套，容易因嵌套层级失效；改用自定义函数，可控性更强
路径参数和查询参数无法进结构体自动绑定
c.BodyParser() 只处理请求体（POST/PUT/PATCH 的 body），它对 /users/:id 或 ?page=1&limit=20 完全无感。Fiber 不做跨源映射，想让这些值进结构体，只能手动提取再赋值。
- 路径参数：用
c.Params("id")拿字符串，再转类型；别直接u.ID = c.Params("id")——底层是字节切片引用，goroutine 或 map 存储时会因内存复用导致竞态 - 查询参数：用
c.QueryParam("page")或c.Queries()分别取，不能塞进结构体靠BodyParser一起解 - 结构体字段若要接收查询参数，得自己写
if pageStr := c.QueryParam("page"); pageStr != "" { u.Page, _ = strconv.Atoi(pageStr) } - 所有手动赋值后，仍需单独校验：比如
u.Page 就该返回 <code>400，别等入库时报错才拦截
最易被忽略的是：校验失败后必须显式 return，否则请求继续往下走；还有 c.Params() 返回的字符串是共享内存，直接赋值给长期存活的对象就是埋雷。
