echo.Context是请求生命周期唯一操作入口，所有参数提取、响应写入等必须通过它完成；c.Param()取路径参数、c.QueryParam()取查询参数，不可混用；c.Bind()不自动合并多源字段；c.Request().Body只能读一次。
直接说结论： echo.Context 不是“上下文容器”，而是请求生命周期的唯一操作入口——所有参数提取、响应写入、中间件跳转、错误中断，都必须通过它完成；漏掉 c 参数或误用 c.Request()/c.Response() 原生对象，是新手最常踩的坑。
怎么从 c 里安全取路径参数和查询参数
路径参数（如 /users/:id）和查询参数（如 /search?name=alice&page=2）不能混用同一个方法获取，且 c.Param() 在参数不存在时返回空字符串而非报错，容易埋下空指针隐患。
-
c.Param("id")只用于路由定义中声明的路径段，比如e.GET("/users/:id", handler)→ 必须传"id"字符串，大小写敏感 -
c.QueryParam("name")获取 URL 查询字符串，未提供时返回空字符串；需要校验时应配合c.QueryParams()检查 key 是否存在 - 若需强制要求某查询参数存在，别靠
if c.QueryParam("x") == ""判断——应改用if val, ok := c.QueryParams()["x"]; !ok || len(val) == 0 - 路径参数不支持嵌套通配符，
/files/:path*中的:path是单段，*后缀才捕获剩余路径，取值用c.Param("*")，不是c.Param("path")
c.Bind() 自动解析 JSON/表单/Query 的边界在哪
c.Bind() 看似万能，但实际只按 Content-Type 和结构体 tag 推断来源，不会自动合并多源字段。例如同时带 query 参数和 JSON body 时，query 不会注入到 struct 字段中，除非显式声明 query:"xxx" tag。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- JSON 请求：Header 必须含
Content-Type: application/json，否则Bind()会静默失败（返回echo.ErrHTTPUnprocessableEntity） - 表单提交：
Content-Type: application/x-www-form-urlencoded或multipart/form-data才触发 form 解析；multipart下文件字段需用c.FormFile()单独取 - Query 绑定：仅当请求是 GET 或 HEAD，且结构体字段 tag 含
query:"name"才生效；POST 带 query 不会自动合并进 bind - 推荐始终检查
err：即使结构体字段全有默认值，Bind()失败也会返回非 nil error，忽略会导致后续逻辑用零值运行
为什么不能直接用 c.Request().Body 读两次
c.Request().Body 是 io.ReadCloser，底层是单次读取流。一旦被 c.Bind()、c.Body() 或手动 io.ReadAll() 消费过，再次读就是空内容——这不是 Echo 的 bug，而是 HTTP/1.1 协议限制。
- 如果需要原始 body 内容（比如做签名验签），应在中间件中用
c.Request().Body读一次，存入c.Set("raw_body", data)，后续 handler 用c.Get("raw_body")取 - 不要在 handler 里反复调用
c.Request().Body；更不要在中间件里读完不重置，否则Bind()会失败 - 若必须多次读，可用
echo.MiddlewareFunc包裹middleware.BodyDump()（官方中间件）或自己用httputil.DumpRequest()缓存 - 注意内存：大文件上传场景下，缓存 raw body 易引发 OOM，此时应改用 streaming 方式处理，绕过
Bind()
真正难的不是记住每个方法名，而是理解 echo.Context 是个不可逆的单向管道：读取动作不可撤回，绑定行为不可覆盖，错误一旦返回就终止链路。多数线上问题，都源于在中间件或 handler 里悄悄消费了 body、覆盖了 context value、或假设参数一定存在。
