c.QueryParam()和c.QueryParams()仅安全获取URL查询参数；完整记录所有请求参数须按Content-Type分路径处理，否则必然漏参。
c.QueryParam() 和 c.QueryParams() 是安全、轻量、无需预处理的获取方式，但仅限 URL 查询参数；想完整记录所有请求参数（比如审计或调试），必须按 Content-Type 分路径处理，否则必然漏参。
GET 请求参数只能用 c.QueryParam() 或 c.Request().URL.Query()
这是最没争议的场景：参数全在 URL 里，c.QueryParam("key") 内部就是调 c.Request().URL.Query().Get("key")，性能无损耗，线程安全。常见错误是误以为 c.FormValue("key") 也能取到 GET 参数——它只查 PostForm，对 GET 无效。
-
c.QueryParam("page")返回单个字符串，空值返回空串 -
c.QueryParams()返回url.Values（即map[string][]string），适合批量读或保留多值语义（如?tag=a&tag=b） - 不要用
c.Request().URL.Query().Get("key")手动取，和c.QueryParam()效果一样，但绕过框架封装，不推荐
POST/PUT 表单参数要先 ParseForm() 才能用 c.FormValue()
application/x-www-form-urlencoded 的 body 不会自动解析，直接调 c.FormValue("name") 可能返回空——因为底层 c.Request().PostForm 还是 nil。必须显式触发解析，且只需一次。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 调一次
c.Request().ParseForm()，之后c.FormValue("name")、c.FormFile("avatar")都可用 - 重复调
ParseForm()没副作用，但没必要；c.FormValue()内部不会自动帮你调，得自己来 - 注意：
c.QueryParam()和c.FormValue()互不影响，GET 参数和 POST 表单参数可同时存在并分别读取
JSON 请求不能靠 c.Bind() 后再取原始 body
c.Bind() 确实能自动解析 JSON 到 struct，但它内部已经读了 Body 流，此时再 io.ReadAll(c.Request().Body) 会得到空字节切片，日志里记到的是空字符串。
- 若需记录原始 JSON 字符串，必须在
c.Bind()前手动读取：body, _ := io.ReadAll(c.Request().Body) - 读完后立刻重置：
c.Request().Body = io.NopCloser(bytes.NewBuffer(body))，否则后续c.Bind()失败 - 生产环境务必加长度限制，例如
body = body[:min(len(body), 1024)]，避免大 payload 耗尽内存
中间件里统一记录参数时，Content-Type 是分水岭
硬写一个“万能取参函数”只会漏掉至少一半参数。真实请求中，query、form、json、multipart 四类参数物理位置完全不同，没有共享存储层。
- 先读
c.Request().Header.Get("Content-Type")，再分支处理 -
multipart/form-data必须用c.MultipartForm()，不能和ParseForm()混用，否则 panic - 别试图用
c.Request().URL.Query()代替全部——它永远拿不到 body 里的任何东西 - 路径参数（
c.Param("id")）是第三类独立来源，也得单独加进去，不属于 query/form/json 任一者
最易被忽略的点：中间件里读完 Body 后忘了重置，导致下游 handler 的 c.Bind() 或 c.JSON() 解析失败，报错像 invalid character '}' looking for beginning of value —— 这不是数据问题，是流被吃掉了。
