必须确认路由是否定义为命名参数（如/user/:id），Iris的c.Params()仅对冒号语法有效；静态路径或通配符路由无法提取参数，中间件中应使用c.Params().Get("id")而非弃用的c.Param("id")。
中间件里拿不到 c.Params()？先确认路由是否带命名参数
Iris 的 c.Params() 只对命名参数（如 /user/:id）有效，如果路由是静态的（如 /user/123）或用了通配符（/user/*），c.Params() 会返回空。中间件执行时路由已匹配，但参数提取依赖路由定义本身。
实操建议：
- 检查路由注册是否用了冒号语法：
app.Get("/api/user/:uid", handler)，而不是/api/user/{uid}或/api/user/123 - 在中间件中用
c.Params().Get("uid")获取，不是c.Param("uid")（后者是旧版 API，已弃用） - 若需兼容多种路由风格，优先改用
c.URLParam("uid")—— 它从 URL 查询字符串、表单、JSON body（需提前绑定）多处尝试提取，但不读命名参数
c.FormValue() 和 c.PostValue() 的区别在哪
这两个都用来取请求体字段，但行为不同：前者会自动从 application/x-www-form-urlencoded 和 multipart/form-data 中解析，后者只读原始 POST body（且仅限于非 multipart 场景）。
常见错误现象：上传文件时用 c.PostValue("name") 拿不到值，因为 multipart body 需先调用 c.ParseForm() 或直接用 c.FormValue()。
实操建议：
- 表单提交（含文件）统一用
c.FormValue("field") - 纯 JSON 请求体，别用这两个——应先调用
c.ReadJSON(&v)或c.ReadBody()解析后再取字段 - 中间件中调用
c.FormValue()前，确保没其他中间件已读过 body（Iris 的 body 只能读一次）
中间件里读 c.URLParam() 返回空？检查查询字符串格式
c.URLParam("q") 对应的是 URL 查询参数（?q=abc），不是路径段。它不区分 GET/POST，但要求参数真实存在于 URL 中，且未被其他中间件提前消费。
容易踩的坑：
- 前端发请求时漏了
?，比如写成/search?q=abc&（末尾多 &）或/search?q=abc被代理截断 - 使用了 URL 重写（如 Nginx 的
rewrite），但没把查询字符串带过去（需加?后缀） - 中间件顺序问题：若你写了自定义 body 读取逻辑（如
c.ReadAllBody()），会清空原始请求，导致后续c.URLParam()失效
为什么 c.QueryArgs() 返回空，但 c.Request.URL.Query() 却有值
c.QueryArgs() 是 Iris 封装的快速访问器，内部缓存了 URL 解析结果；而 c.Request.URL.Query() 是原生 net/http 的 map，始终可用。当 c.QueryArgs() 返回空，大概率是请求 URL 格式非法（如未编码的空格、中文、特殊符号）导致 Iris 解析失败。
实操建议：
- 调试时优先用
c.Request.URL.RawQuery看原始查询字符串长什么样 - 中文或特殊字符必须用
encodeURIComponent（前端）或url.PathEscape（后端生成链接时）处理 - 不要在中间件里反复调用
c.QueryArgs()——它不缓存失败结果，每次调用都重新解析，性能差还容易误判
