中间件不是Iris参数校验的推荐路径，应优先使用路由宏（如{id:uint64}）、结构体binding标签和controller内显式判断；因中间件执行早于路由匹配、难维护、易绕过且无法替代路由层过滤能力。
中间件不是 Iris 参数校验的推荐路径——它容易绕过、难复用、还可能掩盖路由层本可拦截的问题。真正该用的地方是路由宏、结构体 binding 和 controller 内显式判断。
为什么不该在中间件里做通用参数校验
中间件执行时机早于路由匹配，但你通常只对特定路径（比如 /users/{id:uint64}）或特定方法（比如 POST /api/orders）有校验需求。在中间件里写一堆 if ctx.Path() == "..." + switch ctx.Method() 判断，既难维护，又容易漏掉新路由；更关键的是，它无法替代路由宏在 radix tree 匹配阶段就拒绝非法输入的能力。
常见错误现象：
- 写了中间件校验
id是否为正整数，但请求/users/abc仍进了 handler —— 因为没配{id:uint64}宏，中间件拿到的ctx.Params().Get("id")就是空字符串，你还要额外判空、转类型、处理 error - 中间件里调了
ctx.URLParamInt("page")，但忘记if err != nil就 panic，而这个 panic 会暴露堆栈给前端 - 多个中间件叠加时，校验逻辑被重复执行（比如鉴权中间件和参数校验中间件都去读同一段 JSON），浪费 CPU 且增加竞态风险
ctx.ReadJSON + 结构体 binding 标签才是正解
Iris 的 ReadJSON 方法天然支持 go-playground/validator 的 binding tag，只要提前给 app.Validator 赋值，就能在反序列化时一并完成字段级校验，比中间件干净得多。
实操要点：
- 必须初始化 validator 实例并赋给
app.Validator，否则所有binding标签静默失效：app.Validator = validator.New() - 结构体字段必须导出（首字母大写），且带
jsontag 映射字段名，否则绑定失败 -
binding:"required"对空字符串、零值、nil 切片都生效；binding:"email"会校验格式；binding:"min=1,max=100"适用于分页size字段 - 校验失败时
ctx.ReadJSON(&req)返回validator.ValidationErrors类型 error，别用err.Error()直接返回给前端，建议提取字段+规则摘要（如"size: must be between 1 and 100"）
路由参数必须用宏，别等进中间件再查
路径里的 {id} 是最该被“卡死”的参数类型。Iris 允许你在路由定义里直接写 {id:uint64} 或 {id:int min(1) max(999999)}，这类宏在请求匹配阶段就过滤掉非法值，根本不会触发任何 handler 或中间件。
容易踩的坑：
- 写了
{id}却没加类型，比如/user/{id}→ 请求/user/abc时ctx.Params().GetUint64("id")返回0, error，但 handler 已执行 - 用了自定义宏（如
oid:int min(1)）但忘了调app.Macros().Register，Iris 静默忽略整段宏，等于没写 - 宏语法写错，比如
min1而非min(1)，同样静默失效 -
{path:path}类型不自动解码，ctx.Params().Get("path")拿到的是"a%20b/c.txt"，得手动调url.PathUnescape
查询参数和表单字段只能手动校验，中间件不是银弹
?page=1&size=20 或 application/x-www-form-urlencoded 数据不走结构体绑定，Iris 不提供自动校验能力。这时确实要写逻辑，但应放在 controller 方法内，而不是中间件里。
理由很实际：
- 不同接口对
page的要求不同：列表页要>=1，搜索页可能允许0表示“全部” -
ctx.URLParamInt("page")返回(int, error)，你能明确区分 “没传参数”、“传了非数字”、“传了负数” 三种 case，中间件里统一处理反而模糊语义 - controller 里校验后可直接用
page, _ := ctx.URLParamInt("page")（已确认合法），避免重复转换 - 若真要用中间件封装共用逻辑（比如统一检查
trace_idheader），务必限制作用域：用api.Use(paramCheckMiddleware)而非app.Use()，防止污染健康检查等免校验路由
真正复杂的是多层校验的组合：路由宏拦住明显非法值，结构体 binding 拦住 JSON 字段逻辑错误，controller 内再做跨字段约束（比如 start_time < end_time）——中间件夹在中间，既不够早，也不够细，还容易被绕过。
